打开 LangChain 文档看了两周，一行能跑的 Agent 都没写出来——这是入门期最典型的状态。问题不在人，在顺序：Agent 的内核小得惊人，一个大模型调用加一个工具执行循环，五十行代码就能跑通。先把这五十行吃透，再谈框架，效率高得多。
内核只有三样东西
抛开各种概念包装，一个能干活的 Agent 就是三件事的组合：
| 组件 | 干什么 | 典型实现 |
|---|---|---|
| 模型 | 推理与决策 | Claude、GPT 系列 API |
| 工具 | 实际执行动作 | 函数调用、MCP Server |
| 循环 | 决定下一步、何时停 | ReAct 主循环 |
规划、记忆这些听起来高级的模块，初期都可以退化成"循环里加几行代码"。真正绕不开的是循环的退出条件——少了它，Token 账单会替你教训一遍。
最简写法是双重保险：设置 max_steps 硬上限，同时约定模型完成任务时输出特定标记（比如 FINISH）。只做第一条会碰到一个隐蔽问题：某些模型在任务完成后并不输出约定标记，而是继续总结，循环只能靠步数上限兜底砍断。所以更稳的设计是把"停止"也做成一个显式工具——模型想结束时主动调用 finish(summary)，由宿主代码捕获这个调用并退出。工具是强契约，文本标记只是君子协定。
路线怎么排：四个阶段，动手优先
第一步（两到三周）：手写循环。 掌握模型 API 的参数语义，写一个能查天气、给建议的助手。重点不是功能，是理解一次工具调用的完整链路：模型返回调用意图、宿主执行、结果回填、模型基于观察继续。这四步在所有框架里都是同一个骨架。
第二步（三到四周）：上编排。 用 LangGraph 之类把循环改成显式的状态图，节点是"调模型""调工具"，边是条件路由。同时把工具封装成 MCP Server，理解工具发现机制。记忆系统这阶段可以只做滑动窗口加自动摘要，向量库不急。
第三步（四到六周）：多 Agent 协作。 顺序流水线、并行扇出、辩论裁决、层级派单，四种通信模式各搭一遍。这里要警惕成本陷阱：每加一个 Agent，Token 消耗近似翻倍，先算账再动手。
第四步（持续）：生产化。 沙箱执行、审计日志、护栏、评估体系。这一步没有毕业日期，跟着真实事故学最快。
缓存省钱的正确姿势
Prompt Caching 是最容易被忽略的降本手段，也是最容易被用错的一个。它的生效前提是前缀完全一致：把系统提示放在消息序列最前面，并打上缓存断点，命中后这部分输入按一折左右计费。
常见的翻车方式是把动态内容混进了前缀——当前日期、随机 ID、用户名，任何一处变动都会让缓存从那个位置开始全部失效。正确做法是前缀只放稳定内容（角色设定、工具定义、规则），可变信息放到消息尾部。上线前建议用连续两次相同请求验证：第二次的响应里缓存读 Token 应该占大头，否则说明前缀被污染了。
评估不做，改版就是赌博
Agent 改了提示词之后效果变差，靠肉眼根本看不出来。一套最低成本的评估配置长这样：
- 用例分层：五十个以上测试用例，覆盖三类——该调工具的、不该调工具的、工具执行失败要兜底的。只测成功路径的评估集没有价值。
- 判分可自动化：工具选择对不对、参数提取对不对、任务是否完成，三项都可以写成程序判定，不需要人逐条看。
- 改动必跑：提示词、模型版本、工具描述任何一项变更，评估集全量跑一遍，和上一版对比通过率。
有这套流程在，才敢在半夜放心改配置。
前人踩过的坑
| 坑 | 现象 | 解法 |
|---|---|---|
| 一上来学框架 | 文档看完仍写不出东西 | 先手写五十行循环 |
| 工具描述敷衍 | 模型选错工具或乱传参数 | 描述里写清用途、参数含义、返回格式和使用示例 |
| 没有退出条件 | 死循环烧 Token | 步数上限加 finish 工具双保险 |
| 忽略错误处理 | 工具报错直接崩 | 错误信息结构化回喂，让模型换路 |
| 逻辑塞进提示词 | 执行慢且易错 | 代码管逻辑，模型管推理 |
| 缓存被击穿 | 成本降不下来 | 前缀只放稳定内容 |
| 无评估上线 | 退化了也不知道 | 分层用例加自动判分 |
最后说一句心态问题：Agent 开发的门槛在这两年降了很多，协议、框架、评测工具都齐了。缺的不是资料，是动手顺序——从五十行循环开始，往上加东西，每一层都清楚自己为什么需要它。
评论0