从 AI Postman 到 AIWorkHelper：我对 Agent 工程化的理解

我一开始做 Agent，想法其实挺朴素的：让模型会调工具，然后多调几次，任务不就做完了吗？

后来做了 AI Postman，再往后做 AIWorkHelper，我才慢慢意识到，Agent 工程化最难的部分根本不是“让模型调用工具”，而是你怎么把一个会说话的模型，变成一个在真实链路里不乱来的系统。

AI Postman 阶段：我以为工具调用就是核心

AI Postman 那时候，我最关注的是三件事：

• 工具描述怎么写。
• 参数怎么让模型填对。
• 多轮调用怎么串起来。

当时觉得这已经挺复杂了，因为只要参数一错、字段一漏，整个请求就发不出去。模型看起来很聪明，但一到真实接口，就经常暴露出“会解释但不会执行”的问题。

那段时间我最大的收获是，Function Calling 不是锦上添花的能力，它本质上是在把模型输出从“自由文本”收紧成“可执行结构”。这一步很重要，因为只要系统要落地，最后都得回到结构化和可校验。

但做着做着我发现，只解决“单次工具调用”还远远不够。

AIWorkHelper 阶段：真正难的是任务闭环

到 AIWorkHelper 这种更像业务助手的场景，问题马上就升级了。

用户不会像你写测试用例那样说话。他会一句话扔过来一个模糊任务，比如：

• “帮我整理一下这个客户最近的跟进情况。”
• “看看这个需求值不值得排期。”
• “把这个周报先起个草稿。”

这种输入的特点是，它不是一个工具调用，而是一个任务起点。中间到底要不要查知识库、要不要查数据库、要不要总结历史上下文、要不要让用户补充信息，全都不是固定答案。

这时候我开始理解，Agent 不是“会自动做很多事”，而是“在不确定任务里，系统怎样稳定地推进下一步”。

我现在理解的 Agent 工程化，核心是这四层

1. 任务拆解

不是所有请求都值得放给模型自由发挥。很多时候要先判断：

• 这是问答型任务，还是执行型任务。
• 是一步完成，还是需要分阶段推进。
• 缺少关键信息时，是继续猜，还是先追问。

如果这一步不做，模型很容易一上来就“积极行动”，结果做了一堆看起来努力、实际上跑偏的事情。

2. 上下文治理

我现在越来越觉得，Agent 项目最后比拼的不是谁接的模型更多，而是谁的上下文管理更稳。

因为模型每一步的判断都依赖上下文，而上下文最容易失控。典型问题包括：

• 塞了太多历史消息，重点被淹没。
• 旧状态没有清理，影响当前决策。
• 不同工具返回格式不统一，模型读起来很累。

所以真正有用的上下文，不是“尽量多给”，而是“只给当前步骤真正需要的东西”。

3. 工具执行约束

工具不是越多越好。工具一多，模型的决策空间就会变大，误用概率也会上升。

我现在会更在意：

• 哪些工具应该暴露给模型。
• 哪些参数必须由系统补全，不能让模型瞎猜。
• 哪些操作有副作用，必须二次确认。

很多 Agent 之所以不稳定，不是模型太弱，而是系统给了它太多自由，而且没设置护栏。

4. 可观测与兜底

如果一个 Agent 出错后你只能看最终回答，那基本等于没法调。

所以日志不能只记 prompt 和 answer，还要记：

• 当时选了哪个工具。
• 为什么走这条路径。
• 工具返回了什么关键结果。
• 哪一步开始偏了。

只有这样，你才能知道问题是出在模型决策、工具设计、还是上下文污染。

我对“智能感”的看法也变了

刚开始做这类项目的时候，我会比较在意产品看起来聪不聪明。比如能不能自己规划、能不能连着调很多工具、能不能回答得特别像真人。

但现在我的标准变了。我更在意的是：

• 它能不能稳定完成 60 分的任务。
• 出错的时候是不是可预期。
• 不能做的时候会不会老实说不确定。

因为真实业务不是拿来演示“哇，它会自己思考”的。真实业务要的是，别乱做，别乱写，别让用户收拾残局。

一个我现在很认同的判断

Agent 工程化，本质上不是增强模型的“自由”，而是在模型不那么可靠的前提下，设计一个仍然能交付结果的系统。

所以如果现在再让我总结从 AI Postman 到 AIWorkHelper 的变化，我会说：

前者让我理解了工具调用要结构化，后者让我理解了任务系统要工程化。真正的 Agent，不是靠一段 prompt 撑起来的，而是靠任务拆解、上下文治理、工具约束和兜底机制一起撑起来的。

这也是我现在为什么对“全自动 Agent”这种说法会天然保留一点。