智能体交付的七个坑：为什么“能跑”离“能服务客户”还很远

开发者做智能体时，常常先验证一条链路：用户输入，模型回答，必要时调用工具。链路跑通以后，团队很容易误以为项目已经完成了大半。事实上，客户交付阶段最难处理的，往往是那些在 Demo 中没有出现的问题。

1. 没有把任务拆成可验收的输入和输出

“做一个客服智能体”“做一个行业助手”都太宽泛。工程上应把任务缩小到可验收范围。

例如，会展服务团队第一期可以只做“咨询交付检查”：输入是客户问题和运营已确认资料；输出是答复草案、缺失信息、人工确认事项、建议下一步。这样既能立刻减少整理工作，也不会把价格、订单、审核等高风险动作交给模型。

2. 试图用一个模型节点承担所有职责

复杂任务至少包含理解、规划、生成和校验。把它们全部压进一次生成，容易出现两种问题：模型自行补全未知信息，或者工具调用边界不清。

更稳妥的工程设计是引入职责分层：

• 规划阶段识别意图、事实与缺口；
• 生成阶段输出草案和结构化待办；
• 校验阶段检查动态信息、敏感承诺和越权动作；
• 高风险结果统一进入人工确认。

这不要求每个项目都做复杂多智能体，但必须让每个责任点可观察、可修改、可测试。

3. 客户资料没有隔离

交付伙伴最容易忽视这一点。复制一个智能体时，可能连同知识、工具配置或会话上下文一并复制，后续既难维护，也有客户数据混用风险。

正确的思路是“模板共享，资源隔离”。公共提示词、通用流程、测试集可以复用；客户知识库、业务工具、会话与日志应按项目或租户独立管理。共享不是默认行为，跨项目调用也应有明确授权。

4. 把 MCP 当作万能连接器

MCP 可以让智能体获得受控能力，但不应成为“把所有系统开放给模型”的理由。接入前应先做工具分级：

• 低风险：查询公开规则、读取已授权文件、生成草案；
• 中风险：查询客户业务数据，需要身份校验和结果脱敏；
• 高风险：创建订单、调整价格、审批、付款、修改状态，必须显式人工确认、留痕并可回退。

接口越接近业务结果，权限越要收紧。模型可以提出建议，但不应在缺少规则和审批的情况下直接改变现实状态。

5. 把工具名称写进 Prompt，却没有完成真实绑定

提示词中写“请查询订单系统”，不等于系统已经连通。工程上要分别验证：工具声明、参数约束、身份授权、调用日志、错误处理和降级输出。不能调用时，智能体应说明“当前未接入实时数据”，而不是编造答案。

这也是自编排能力的实际意义：把智能体、知识库、Skills、MCP 服务、文件、模型等对象放在可配置、可追踪的工程流程中，而不是散落在多份 Prompt 和临时脚本里。

6. 没有越界测试

正常问题只能测试“会不会做”，越界问题才测试“知不知道不能做”。

建议每个项目至少保留以下测试：

• 信息完整的常规提问；
• 关键资料缺失的提问；
• 要求绕过权限的提问；
• 带错误参数或冲突指令的提问；
• 不同客户、不同会话的隔离验证。

测试结果应与模型、知识和工具配置一起保存。否则上线后发生偏差，团队很难复现问题。

7. 把发布当作项目结项

客户使用后，规则会变化，模型会迭代，资料会更新，工具接口也可能调整。真正可持续的交付模式，是把发布、反馈、版本、测试、回退和维护纳入日常工作。

好易面向交付伙伴的运营思路，恰好适合这类工作：不是只交付一个入口，而是把客户项目中的能力对象和运营过程沉淀下来。服务商可以从通用模板起步，再为每个客户配置独立资料、能力和入口，持续提供更新与托管服务。

能跑通的智能体是原型；能在资料变化、用户误操作和客户差异中保持边界的智能体，才是可以交付的产品。