工具接口：数量少但要稳
智能体的能力来自工具，接口稳定性比数量重要。立项时应先确认两到四个核心接口的可用性、鉴权方式与错误码规范，接口频繁超时或返回结构漂移，会让智能体表现时好时坏，评测结论也无法稳定复现，团队会陷入互相怀疑。
主数据：决定判断是否可靠
工单、客户、物料、设备这类主数据若不统一，智能体在检索与比对时会得到互相矛盾的结论。主数据治理通常不在 AI 项目范围内，但必须在立项时确认由谁负责，否则问题会被反复归因到模型，改来改去也解决不了。
知识库：结构化到可检索
制度、流程与操作手册需要拆分到条目级，并标注适用范围与生效时间。整篇文档直接入库，检索时容易召回无关段落，智能体据此生成的建议看似合理却与当前政策不符，风险高于答不出，也更难被人工发现。
操作审计与回滚
智能体触发的每一次写操作都要可追溯、可回滚，包括操作人、时间、参数与结果。缺少回滚能力时，一次错误执行可能要求人工逐条修复数据，代价远高于事前设计审计与补偿机制，业务中断时间也难以控制。
独立测试环境
智能体的试错频率高于普通系统，必须有与生产隔离的测试环境，包含工具 mock 与数据脱敏。直接在生产环境调试，容易产生真实副作用，也让评测结果无法复现，后续复盘时根本说不清问题究竟出在哪一步。
适用与不适用
适合谁
- 准备把智能体接入生产系统的企业
- 已有多个业务系统、接口相对规范的组织
- 需要向安全团队说明操作边界的项目
不适合谁
- 核心系统完全不开放接口且短期无法改造
- 无法提供测试环境、只能在生产环境试错的场景
典型场景
某物流企业的智能体项目在立项盘点时发现，运单系统只有查询接口没有幂等控制，重复提交会产生多余记录。团队先让系统方补了幂等键与错误码，再在测试环境用脱敏数据跑了两周，才把改派单动作接入灰度环境，灰度期间又补了两次错误码兼容处理。
可执行步骤
- 列出候选工具接口，逐项确认可用性、鉴权方式与错误码，并记录接口责任人
- 核对主数据的唯一性与口径，明确治理责任部门与负责人，避免多头维护
- 把知识拆到条目级，标注适用范围、生效时间与维护人，并做一次检索验证
- 为写操作补齐审计字段、补偿机制与可执行的回滚方案，并指定回滚负责人
常见坑
- 接口没有幂等设计，智能体重试时产生重复单据，事后清理成本很高，还可能影响对账与客户结算。
- 主数据多头维护，智能体在不同系统查到不同结论，用户不再信任结果，最终回到人工核对的旧流程。
- 知识整篇入库，检索召回无关段落，建议与现行政策冲突，一旦被外部看到就是合规问题；追责时也很被动。
- 直接在生产环境调试，产生真实副作用，还要向客户解释，团队士气与客户信任度同时受损；恢复时间不可控。
自检与验收清单
- 核心工具接口是否稳定且有错误码规范，是否有版本记录
- 主数据口径是否统一并有人负责，是否有明确责任部门
- 知识是否拆到条目级并可检索，是否能被有效召回
- 写操作是否有审计字段与回滚方案，是否演练过
常见问题
接口很少能做智能体吗？
可以，两个接口也能做出有价值的智能体，例如查询加提交。关键不在数量，而在接口是否稳定、语义是否清晰；接口含糊时，再多的工具也只会增加失败路径，反而让排障变得更困难，业务方也更难判断问题出在哪。
主数据没治理好能不能先上？
可以先做只读类智能体，把结论作为参考；涉及写操作或多系统比对的场景，建议先做小范围主数据对齐。否则智能体会把数据矛盾放大成业务判断错误，后期修复成本更高，也很难界定究竟是谁的责任。
测试环境要和生产一样吗？
不要求完全一致，但关键接口的行为、错误码与限流策略应尽量对齐。差异过大会导致测试通过而生产失败，尤其是超时与并发相关的行为，务必在测试环境复现，否则评测结论没有参考价值。