第一阶段:概念与选型

1. 搞清楚三个核心概念的关系

  • Function Calling — 模型原生能力,不是框架给的。模型在 API 层面就能识别工具定义并决定是否调用。
  • Tool Use — 上层概念,Function Calling 的产物。模型输出工具调用 → 代码执行 → 结果返回模型。
  • Skill — 工具 + Prompt 的打包单元。一组相关工具配上一段触发指令,按场景加载。
  • MCP — 工具定义和 Agent 代码解耦的标准协议。通过统一接口发现和调用远程工具/数据源。

2. 选技术路线

路线 特点 适合谁
纯 API + 手写循环 无框架依赖,理解本质 学习阶段、需要精细控制
LangChain + LangGraph 生态最大,内置循环和管理 快速搭建、需要中间件等高级功能
Semantic Kernel 微软出品,架构清晰 .NET 生态、企业级
Dify / Coze 可视化编排,低代码 快速出活、非开发者

第二阶段:基础设施搭建

3. 搭模型接入层

  • 不要只绑一个模型,抽象成统一接口
  • 考虑多模型混用:推理用强模型,分类用轻量模型,向量化用嵌入模型
  • 接入层需要支持:chat、stream、embed 三种模式

4. 搭 Function Calling 管线

  • 核心循环:用户输入 → [系统Prompt + 历史 + 工具定义] → 模型
  • 模型输出结果:文本回复直接返回,tool_calls 执行函数后结果回送模型
  • 工具定义(tool schema)用 JSON Schema 格式,description 字段直接影响模型调用准确率
  • 一次返回多个 tool_calls 时可并发执行,注意依赖关系

5. 设计工具

原则 说明
职责单一 每个工具只做一件事,模型才好决策
入参语义化 用人类理解的描述,不要传内部 ID
无隐式依赖 每个工具应能独立调用,不依赖调用顺序
谨慎暴露 只有需要模型主动决策是否调用时才暴露为工具

第三阶段:Skill 体系

6. 把工具打包成 Skill

  • Skill = 一组工具 + Trigger Prompt
  • 工具 >10 个时模型会混乱,Skill 是分层解决思路
  • 加载方式:
    • 静态:所有 Skill 一股脑塞给模型(适合少场景)
    • 动态:路由模型先判断意图,再只加载对应 Skill(适合 10+ 场景)

7. 实现 Skill 路由

  • 用 Function Calling 做分类比用 Prompt 分类稳定得多
  • 二级架构:分类器 → 对应 Skill 加载 → 推理模型执行
  • 分类器可以用轻量模型,甚至规则匹配

第四阶段:集成 MCP

8. 通过 MCP 接入外部工具

  • MCP 将工具定义和 Agent 代码解耦
  • 以前:手写 HTTP 请求 + 解析
  • 现在:搭 MCP Server 暴露接口,Agent 只管调用
  • 适用场景:文件系统、数据库、第三方 API、内部业务服务

第五阶段:状态管理

9. 管理三种状态

状态类型 内容 管理策略
对话历史 消息列表 长对话要压缩或裁剪(摘要/滑动窗口/保留最近 N 轮)
Runtime Context 当前工具调用状态、已获取信息 Agent 执行过程中维护
Persistent State 用户身份、偏好、跨会话数据 持久化存储

10. 流式输出

  • Function Calling + 流式同时做时,tool_calls 可能出现在 stream 中间
  • 策略:缓存 tool_call 片段,stream 结束后再执行工具
  • 工具执行结果不再流式,直接送入模型

第六阶段:RAG

11. Agentic RAG

  • 检索本身作为 Agent 的一个工具
  • Agent 主动决定何时检索、检索什么、检索几次
  • 比"每次都检索"更灵活

12. 知识库管线

  • 文件 → 加载 → 分块 → 向量化 → 存入向量库
  • 分块大小 200-500 token 起步,根据内容类型调整
  • 向量检索 + BM25 关键词搜索混合取效果更好
  • 检索结果建议加 reranker 重排序

第七阶段:多 Agent(按需)

13. 判断是否需要多 Agent

  • 不需要多 Agent 就不上
  • 需要的情况:任务跨领域知识、目标冲突、需并行大量子任务
  • 架构:Supervisor 分配 → 子 Agent 执行 → 结果合并

第八阶段:评估

14. 评估四维度

维度 测什么
工具调用准确率 该调的时候调了没?不该调的时候没调?参数对不对?
多轮成功率 需要多步工具调用的任务最终完成没有?
效率 调了多少次不必要的工具?走了多少冤枉路?
安全 用户诱导越权操作时有没有防御?工具输入有没有注入防护?

15. 迭代流程

  • 写测试用例:每个工具 5-10 个典型场景,标注预期行为
  • 自动化跑分:批量测试统计准确率
  • 人工抽检:重点关注边缘情况

核心认知

Agent 开发的本质是三个东西的配合:模型能力 × Prompt 约束 × 工具边界。 模型决定上限,Prompt 和工具决定实际表现。先让"一句话问答→调一个工具→返回结果"的链路跑通,再逐步加场景,不要一开始就搭大架构。

Logo

中国智能体开发者社区,聚焦智能体与大模型开发,提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动,促进经验交流与协作,助力开发者快速构建创新智能应用。

更多推荐