先给结论：Agent 会“做事”后，错误就会产生业务后果

一个只生成文本的模型，错误通常先表现为答案不准确；一个可以查询、修改、发送、审批或触发流程的 Agent，错误可能直接改变业务状态。因此，Agent 进入生产前必须先定义它理解的业务对象、允许执行的动作、需要人工确认的边界，以及出现问题时如何停止和恢复。

这不是给 Agent 增加一层形式化文档，而是把“它能做什么”从提示词里的愿望变成系统可以检查的约束。

从业务语义到动作控制的五个问题

1. Agent 正在处理什么业务对象

先列出订单、客户、库存、合同、工单等对象，以及对象之间的关系、状态和数据来源。没有对象和关系，Agent 很难区分“读取一个订单”和“修改订单状态”之间的风险差异。

2. Agent 可以执行哪些动作

把动作写成可审查的动词：查询、推荐、创建、修改、发送、审批、关闭。每个动作都应绑定输入、目标系统、幂等规则和失败处理，而不是笼统地写“让 Agent 自动处理”。

3. 哪些动作需要人工批准

涉及资金、外部沟通、权限变化、合同状态或不可逆数据变更的动作，通常需要人工确认或分级审批。审批不是为了让人重复点击，而是为了让责任人知道系统即将改变什么。

4. 如何审计和恢复

每次调用至少应能追溯输入来源、模型或策略版本、工具调用、最终动作、批准人和结果。系统还要有停止开关、补偿动作、人工接管和回滚路径；只有“记录日志”而没有恢复能力，不足以应对生产故障。

5. 用什么业务证据判断值得继续

Agent 的质量不能只看回答准确率。还要观察处理时间、返工率、人工接管率、异常率、用户采用和业务 Owner 的目标。对于不同风险等级的动作，指标和放行门槛应在测试前冻结，而不是上线后临时解释。

一张最小控制表

控制对象上线前必须回答没有答案时的处理
数据数据来自哪里、多久更新、谁能看先限定数据范围或暂停自动动作
动作能做什么、不能做什么、是否幂等改为只读、建议或人工执行
权限是否最小权限、谁批准敏感操作拒绝管理员权限和无审批上线
恢复如何停止、补偿、回滚和交接只允许可逆或低风险灰度
结果谁负责指标、何时停止、如何复盘不把技术 Demo 宣布为生产成功

FDEr.ai 的判断

企业 Agent 落地的关键不是把模型接入更多系统，而是先把业务对象、动作和责任边界说清楚，再逐步扩大自动化范围。FDE 的价值也不只是把接口连通，而是让每一次动作都能被授权、被观察、被解释，并在失败时回到人工流程。

如果一个项目无法回答“它会改变什么、谁批准、如何恢复”，最合理的下一步通常不是继续调 Prompt，而是缩小动作边界，回到上下文梳理和生产准入。