Agent 应用开发技术学习笔记#

3.1 LangChain#

LangChain 生态大、连接器丰富，适合需要同时集成多种模型、工具、Retriever 和向量数据库的项目。它更接近组件与集成层；复杂、状态化的 Agent 通常配合 LangGraph。

3.2 PydanticAI#

PydanticAI 强调 Python 类型安全、依赖注入、结构化输出和可测试性。适合已有 FastAPI/Pydantic 技术栈、希望保持代码清晰的后端团队。

3.3 OpenAI Agents SDK#

OpenAI Agents SDK 提供 Agent、Runner、Tools、Handoffs、Guardrails、Sessions 和 Tracing。适合主要使用 OpenAI 模型，希望用较少抽象快速构建工具型 Agent 的项目。

4.1 LangGraph#

LangGraph 将 Agent 表达成有状态图：Node 是模型、工具或普通代码，Edge 表示执行路径，State 保存共享状态，Checkpoint 用于中断与恢复。

它适合客服工单、研究报告、编码 Agent、审批流程，以及需要明确控制执行路径的长期任务。

1
LangChain：模型、Agent 和工具集成
2
LangGraph：状态、流程和执行控制
3
LangSmith：Tracing、评测与监控

三者属于同一生态，经常组合使用，并非三选一。

4.2 CrewAI#

CrewAI 用 Agent、Task、Crew 和 Flow 表达角色式协作，适合研究、内容生产、市场分析等天然具有角色分工的任务。

多 Agent 并不天然优于单 Agent，它通常增加 Token、延迟、错误传播和评测难度。应先验证“单 Agent + 明确工作流”无法满足需求，再引入多 Agent。

4.3 Google ADK 与 Microsoft Agent Framework#

• Google ADK 适合 Gemini、Google Cloud、多语言 SDK 和多 Agent 场景。
• Microsoft Agent Framework 适合 Azure、Microsoft 365、.NET 和企业身份体系。AutoGen 与 Semantic Kernel 的新项目应关注微软统一后的 Agent Framework 路线。

5.1 LlamaIndex#

LlamaIndex 擅长文档接入、解析、索引、检索、Query Engine、RAG 和数据型 Agent，适合企业知识库、研究助手和文档分析。

5.2 Haystack#

Haystack 以 Document Store、Retriever、Component 和 Pipeline 为核心，适合企业搜索、文档问答和复杂检索流程。

简单选择：

• 文档、知识库和数据 Agent：优先比较 LlamaIndex 与 Haystack；
• 通用业务 Agent：优先比较 LangGraph、PydanticAI 与 OpenAI Agents SDK。

6.1 Pi Agent Harness#

Pi 是 TypeScript monorepo，主要包含：

• pi-ai：统一多模型 API；
• pi-agent-core：Agent runtime、工具调用和状态管理；
• pi-coding-agent：交互式编码 Agent；
• pi-tui 与 pi-web-ui：终端和 Web UI；
• Extensions 与 Skills 扩展机制。

Pi 核心相对精简，适合读源码、开发自己的 Coding Agent，或者将 Agent Core 嵌入 TypeScript 应用。

6.2 DeepSeek Harness#

DeepSeek Harness（dsh）采用“一切皆插件”的思路，模型、工具、Skills、Session、Sandbox、Storage、Loop、调度和 UI 均可由插件提供。

它的 append-only Session Event Log 支持 Resume、Fork、Replay、Search 和 Trajectory 检查。运行模式包括 Standard、Code、Minimal 和 Creator。

截至本文整理时，它仍处于 Developer Preview，基础 API 可能发生破坏性变化，适合技术预研和插件化运行时研究，不宜未经充分验证直接成为关键生产系统的唯一底座。

6.3 Pi 与 DeepSeek Harness 对比#

选择建议：

• 快速开发自己的 Coding Agent：优先研究 Pi；
• 研究可组合 Agent Runtime：重点研究 DeepSeek Harness；
• 构建稳定的业务流程：优先考虑 LangGraph/PydanticAI 与可靠执行设施；
• 构建 Agent IDE 或开放扩展平台：Pi 和 DeepSeek Harness 都有较高参考价值。

7.1 Dify#

Dify 的主角是 AI 应用，围绕以下能力构建：

• 模型与 Prompt 管理；
• Agent、Workflow 与 Chatflow；
• 知识库、文档解析、Embedding 和检索；
• 会话与上下文；
• Web App 与 API 发布；
• AI 调用日志和运营。

适合企业知识助手、客服机器人、文档问答、内容生成和 AI 产品 MVP。

7.2 Flowise 与 Langflow#

• Flowise 偏向 AgentFlow、多 Agent 和复杂节点编排；
• Langflow 偏向 LangChain 组件、RAG 与 MCP 的可视化实验。

低代码平台适合快速验证，但核心业务规则过多时，可视化画布会变得难以测试、Code Review 和版本管理。重要逻辑应逐步下沉到独立代码服务。

9.1 为什么会觉得 n8n 更技术#

n8n 更接近“可视化后端代码”，使用者经常需要处理：

• 节点输入输出和 JSON 字段映射；
• API 鉴权、分页与限流；
• 循环、批处理和数据转换；
• 超时、重试和失败分支；
• 外部数据库与系统状态。

Dify 隐藏了更多 AI 基础设施，但深入使用同样需要理解 Prompt 可靠性、文档切分、检索召回、上下文长度、幻觉和评测。

因此更准确的说法是：

n8n 的门槛偏传统软件工程，Dify 的门槛偏 AI 工程。

9.2 推荐组合方式#

1
用户 / 定时器 / Webhook
2
          ↓
3
         n8n
4
   获取并整理业务数据
5
          ↓
6
      调用 Dify API
7
   RAG、推理、生成结果
8
          ↓
9
         n8n
10
审批、入库、通知、更新系统

10.1 协议与工具接口#

• MCP：连接 Agent 与工具、数据源；
• A2A：用于 Agent 之间的发现和通信；
• OpenAPI / JSON Schema：定义传统服务与 Tool 接口；
• AG-UI：处理 Agent 与前端之间的事件交互。

新项目应优先设计清晰、强约束的 Tool Schema。有跨客户端复用需求时，再将工具封装为 MCP Server。

10.2 可靠执行#

Temporal、Restate、DBOS 和 Prefect 可用于解决：

• 超时和自动重试；
• 断点恢复；
• 长时间等待人工审批；
• 幂等性和外部副作用；
• 工作流版本升级。

转账、下单、发消息和修改生产数据等工具必须设计幂等键、权限校验和操作日志。

10.3 可观测与评测#

常见产品包括 LangSmith、Langfuse、Phoenix、Braintrust、Logfire 和 W&B Weave。至少需要记录：

• 每次模型调用和工具调用；
• Prompt、模型版本和参数；
• Token、成本与延迟；
• 最终状态和失败原因；
• 用户反馈与离线评测结果；
• 工具调用正确率和任务完成率。

没有评测集时，频繁修改 Prompt 很容易沦为凭感觉调参。

10.4 安全#

Agent 能执行外部操作，因此应专门设计：

• Prompt Injection 防护；
• 工具最小权限；
• 写操作人工审批；
• 容器或虚拟机沙箱；
• 密钥隔离和 PII 脱敏；
• URL、文件访问边界；
• 调用次数和预算限制；
• 完整审计日志。