从 Codex 到业务交付：智能体项目最容易漏掉的六个环节

很多团队第一次用 Codex、WorkBuddy 等工具搭智能体时，会把注意力放在“模型回答得够不够聪明”。

真正进入客户项目后，返工通常来自另外六件事：

资料来源不清
客户配置混用
工具权限过大
测试集缺失
发布没有回退
上线后没有运营入口

今天搭建的“智能体交付前检查助手”，就是围绕这些问题设计的。

Demo 如何工作？

它接收客户需求，先识别客户行业、用户、原流程、数据来源、系统入口和风险等级。

然后输出六部分交付清单：

1. 首期 MVP；
2. 模型与节点设计；
3. 知识库、模板、Skills、MCP/API 的选择；
4. 客户隔离、权限、人工确认和日志；
5. 测试问题；
6. 发布与持续托管计划。

实际节点结构保持最小：

开始节点
  -> 交付规划与边界校验节点

节点使用 deepseek-v4-flash，并启用评估回路。这里的目标不是让智能体“代替项目经理”，而是防止交付方案遗漏关键边界。

1. 不要把客户资料塞进 Prompt

客户 SOP、FAQ、品牌资料、合同规则等稳定内容，应在客户授权后放入独立知识库。

不同客户、不同城市、不同门店的知识库应默认隔离。能共享的是经过审核的通用模板、模型服务、通用 Skills 和测试方法，而不是原始业务资料。

2. 不要把模板和知识库混为一谈

知识库回答“事实是什么”。

模板回答“结果应该长什么样”。

例如售后工单助手的输出模板可以固定为：

工单摘要
推荐分类
回复草稿
待补充信息
人工确认提示

这样模型换了、资料更新了，交付物仍然可比较。

3. Skills 和 MCP 不是越多越好

Skills 适合封装重复动作，例如分类映射、表格整理、报告导出。

MCP/API 适合实时数据读取、跨系统协作和受控写入。

第一期没有真实接口、没有明确价值和权限时，不应为了“看起来完整”就接 MCP。今天的 Demo 因此没有绑定外部 MCP 或 Skills。

4. 高风险动作一定要拆开

越界测试中，用户要求自动退款、自动结案、修改 SOP、删除日志。

助手没有给出直接执行方案，而是要求：

AI 生成草案
-> 客服或主管确认
-> 具备权限的人执行
-> 保留审计日志

这比“智能体帮你自动办事”更符合企业交付的责任边界。

5. 自编排 MCP 的实际价值

好易自编排 MCP 可让交付伙伴通过统一链路操作智能体、模型、知识库、Skills、MCP 服务和文件。

这意味着团队不只是手工点页面，而是可以把成熟的交付流程沉淀为模板：

需求卡片
-> 选择模型
-> 创建编排
-> 绑定客户资源
-> 调试测试
-> 发布
-> 运营反馈
-> 版本升级

调用前仍需读取实时契约。工具名称写入提示词，不等于工具已绑定；文件上传成功，也不等于知识问答链路已经验收。

6. 当前验证结果

正常售后场景测试通过节点质检。越界场景同样通过质检，能拒绝自动写入和删除日志要求。

当前未完成客户资料导入、真实工单 API 接入、跨城市复制和生产日志对接。它们应在客户授权、接口校验和小范围试点后再推进。

智能体交付不是“用哪个工具生成得更快”，而是能否把需求、能力、权限、测试和运营真正组织成可维护的项目。