当AI Agent从'听懂问题'到'办成事'之间，隐藏着工程系统的致命鸿沟。本文以员工智能助手为例，深度拆解权限校验、API调用、数据转换等真实场景中的系统级难题，揭示如何通过三层兜底策略和结构化模板，让AI服务从'回答正确'升级为'可靠交付'。

年初我做员工智能助手的时候，遇到了一个特别扎心的事。

模型明明答对了问题，但事没办成。

场景是这样的：员工问”帮我查一下上个月的任务执行情况”。模型理解得很准确，给出了完美的回答——”好的，我来查上个月的任务数据”。然后呢？

然后它卡住了。

因为查任务要调 API，API 需要权限，第一次调用超时了，重试之后返回了数据，但数据格式跟预期不一样，模型又没做二次处理，直接输出了一段让人看不懂的原始字段。

模型听懂了，但事没办成。

这件事给了我一个很大的冲击。那会儿我意识到一件事：AI Agent 的工程难点，从来不是”模型不够聪明”，而是”系统不够可靠”。

从”回答”到”完成”，中间隔了一整层工程系统。今天就想聊聊这层系统长什么样。

第一环：感知——听懂只是开始

员工说了一句话：”帮我查一下上个月的执行情况。”

你觉得你听懂了，但模型不一定。

“上个月”是哪个月？如果今天是 1 月 5 号，”上个月”是 12 月还是今年 1 月？”执行情况”是什么？是任务完成率、还是具体到每个人的进度、还是只看异常？一些隐含的信息：这个员工是什么部门的？他有什么权限？他能看哪些数据？

这些在人类对话里根本不成问题，但在模型这里，每一条都是潜在的坑。

我们当时的做法是：不指望模型一次猜对，而是在第一轮就主动问清楚。

不是简单地问”你要查什么”，而是带着上下文问：”我看到你提到了上个月的执行情况，具体是指任务完成率，还是异常记录？另外我查了一下你的权限范围，你可以查看团队 A 和团队 B 的数据，你看查哪个团队？”

这么做的好处是：把歧义消灭在执行之前，而不是等做错了再返工。

第二环：规划——把大问题拆成小步骤

感知完了，模型知道员工要什么了。接下来是规划：怎么完成这个请求。

比如这个请求：”查一下上个月的任务。”

模型需要自己拆成几步：

1.先调用任务 API，拉取上个月的任务记录

2.再调用考核 API，获取上个月的考核要求

3.把任务记录和考核要求进行比对，找到异常

4.根据类型分类整理（超出、达标、不合格等）

5.生成一份可读的报告

这里有一个很容易忽略的问题：模型拆出来的步骤不一定对。

比如它可能先调了考核 API 再去调任务 API。顺序颠倒了，但结果可能一样，只是效率低一点。但有时候它会漏掉关键步骤——比如忘记检查员工是否有补卡申请记录。

我们当时的做法是：给模型一个”必选步骤清单”，而不是让它完全自由发挥。

比如查任务数据这个场景，我们把关键路径固化成了一个模板：

第一步必须是权限确认

第二步才是数据拉取

第三步是做比对分析

最后是结果整理

模型可以在每个步骤内部自由发挥，但骨架是固定的。这样既保证了灵活性，又不会漏掉关键环节。

这一点后来被证明是项目里最重要的决策之一。

第三环：执行——最容易出事的环节

规划完了，开始执行。

这是整个流程里最容易出事的地方，没有之一。

模型调 API，会遇到各种各样的问题：

• 超时：内部系统响应慢，等了 30 秒没回
• 鉴权失败：token 过期了
• 数据异常：API 返回了 200，但 body 是空的
• 格式不对：预期是 JSON，但返回了一段错误文本

我们是怎么处理的？三层兜底策略：自动重试→ 降级方案 → 人工接管。

第一层：自动重试。超时了？等 2 秒重试一次，再超时等 5 秒，再超时等 10 秒。三次重试都不行，进入第二层。幂等操作可以放心重试，非幂等的操作必须谨慎——这也是为什么第一步要先规划好哪些是只读操作。

第二层：降级方案。拿不到实时数据，能不能用昨天的缓存？API 直接调不通，能不能通过导出报表间接获取？降级的核心逻辑是：给不出最优答案时，给一个次优答案，但不要什么都不给。

第三层：人工接管。降级也行不通了？记录下来，转人工处理。转人工不是简单地说”系统出错了”，而是带着上下文转：把用户问了什么、模型查到了哪一步、出了什么错、已经尝试了什么方案，全部整理好，人工接手的时候一眼就能看懂。

说白了，一个好的 Agent 系统，要从骨子里接受一件事：一定会出错，关键是怎么优雅地出错。

第四环：反馈——闭环的最后一步

执行完了，数据拿到了，报告也生成了。接下来呢？

很多系统到这里就结束了。但真正的”完成”不是输出结果，而是确认结果被接收。

我们的员工助手会多做一步：追问引导。

比如查完任务异常之后，它会说：”以上是上个月的任务执行记录，其中你本人有 3 次未完成。你记得这3个任务安排了吗？”

这里面有几层考量：

第一，确认信息有用。有时候模型查出来的东西用户根本不关心。追问一下，如果用户说”我不是问这个”，还有机会纠正。

第二，把一次性查询变成持续服务。一次查询回答完了，对话就断了。但如果追问引导做得好，可以从”查任务”延伸到”如何做好任务”，再到”发起任务补做”，形成一个完整的服务闭环。

第三，降低下次对话的成本。会话上下文保留下来，下次再说”查任务”的时候，可以将上次操作的记忆带入，加快查询速度。为什么是现在？——这四步能跑起来的技术基础

你可能会问：你说的这四步，听起来不复杂，为什么以前做不了？

因为支撑这四步的技术能力，是这几年才逐步到位、逐步成熟的。不是我们变聪明了，是工具箱终于够了。

第一，Function Calling / Tool Use。这是执行环节的命脉。2023 年之前的模型，输出是不可控的自然语言，你没法让模型稳定地输出结构化 API 调用。2024 年后，主流模型都支持了声明式工具定义，模型能输出格式严格的 JSON 来调用 API。这一步稳了，后面的所有环节才有了基础。

第二，MCP 协议（Model Context Protocol）。2024 年末 Anthropic 推出 MCP 之前，每个工具的接入都要写胶水代码。MCP 标准化了工具发现、输入输出 schema、安全策略，让模型可以动态发现和调用各种系统——就像 USB-C 统一了外设接口。你的员工助手要接考勤系统、审批系统、报表系统，如果是 MCP 协议接入，每个系统只需要写一个 server，剩下的模型自己搞定。

第三，长上下文窗口。从 GPT-3 的 4K，到 Claude 的 100K，到 Gemini 的 1M。以前规划稍微复杂一点的任务，中间步骤的推理过程就把上下文占满了。现在百万级的上下文，模型可以记住整条任务链——从用户说的话，到拆解的计划，到每一步执行的结果，再到反馈。规划不会因为”忘了前面说了什么”而断掉。

第四，Chain-of-Thought 推理能力。”一步一步思考”这个能力，是从 2022 年才被真正激活的。没有它，模型拆解任务的能力约等于零。现在模型可以把”任务查询”自然拆成”先鉴权→再拉数据→再做比对→再整理报告”，这个能力是规划环节的技术基石。

第五，Structured Output。输出格式可控。你不只是让模型”尽量输出 JSON”，而是可以严格约束输出字段的类型、范围、枚举值。下游系统接到模型输出时，不需要再做一层解析和校验。这一步让模型跟工程系统的对接从”手工活”变成了”自动化”。

它们五者不是并列关系，而是分层递进、互相咬合的：

Chain-of-Thought 让模型会思考→ 规划环节才有了技术基石；Function Calling 让模型能动手→ 执行环节才能调 API；Structured Output 让模型做得准→ 规划和执行之间才能无缝对接；长上下文让模型能记住→ 四步才能串成完整的任务链；MCP 协议让这一切可以规模化→ 从”手工接入每个工具”升级为”平台化的工具生态”。

缺任何一条，这四步都跑不起来。

说白了，不是模型突然变聪明了，而是工程生态把这些能力可编程地暴露给了模型。2023 年你想做这四步，每步都要自己发明轮子。现在不需要了，工具箱已经够用了。一些想说的话

回头看这个项目，我最大的感受是：

模型能答对问题和能做完一件事，中间差了一整套工程系统。

感知层要处理歧义，规划层要兜底漏步骤，执行层要准备三套方案，反馈层要保证信息闭环。每一个环节出问题，结果都是”事没办成”。

但反过来想，这也是做 Agent 工程最迷人的地方：模型能力在涨，但系统的可靠性不会自动涨——得你来设计、你来保障。

那些通用的模型能力大家迟早都有，但工程系统的设计质量，最后会成为真正的分水岭。