把 AI 真正部署进业务，而不只是做一个 Demo。

Agent 产出与业务完成之间还隔着一条证据链

一个 Agent 可以成功调用工具、生成报告或返回“任务完成”，但下游系统中的记录可能没有更新，客户问题可能没有解决，一线人员也可能因为结果不可信而重新检查。只观察模型输出，会把局部动作误认为完整流程已经完成。

真正可管理的系统需要把任务、人员、时间、关键动作、最终状态、异常和人工介入连接起来。管理层应当能够从整体结果向下追溯到具体任务，而不是在客诉或复盘发生后再从多个工具和群聊中拼接事实。

• 任务证据：输入、负责人、开始和完成时间是否被记录。
• 过程证据：调用了哪些数据和工具，关键动作是否成功。
• 结果证据：真实业务系统里的最终状态是否发生变化。
• 异常证据：失败是否可发现、可解释、可重试或升级给人。
• 经营证据：时间、成本、质量、客户或风险指标是否因此改善。

先定义企业需要做出的判断，再决定展示什么

可追溯不是把所有日志堆进一张看板，而是从运营、客诉和管理决策出发，确定哪些事实必须被保留。执行人员需要知道下一步做什么，运营负责人需要发现异常和责任，管理层需要判断总体结果和资源投入。

因此，生产化的重点不是再增加一个 Agent，而是建立从执行到结果的反馈、证据和责任闭环。只有这条链存在，企业才可能持续管理、改进并依赖系统。

FDE 负责跨越模型与业务之间的部署鸿沟

传统工程项目通常从明确需求开始；企业 AI 项目却常常只有一句“希望用 AI 提高效率”。真正要改造的流程、可以调用的数据、不能突破的权限以及失败后的处理方式，都还没有被定义。

OpenAI 对 FDE 的描述很明确：与企业管理者、业务人员和一线团队共同识别高价值机会，重新设计关键流程，并把模型连接到企业的数据、工具、控制机制和业务系统中。项目的终点不是完成演示，而是形成每天都能被使用、能够产生可衡量结果的系统。

• 业务鸿沟：把“模型能做什么”翻译成“哪个经营指标会改变”。
• 系统鸿沟：补齐数据、工具、权限、指令、异常处理、人工审批和审计。
• 组织鸿沟：把依赖个人经验的例外、判断和隐性规则转化为系统能力。

交付物不只是代码

FDE 同时承担问题发现、流程重构、系统集成和生产运营。优秀的交付应当包括明确的业务指标、可靠的工作流、可复用的工具、持续运行的评估体系，以及能够由企业内部团队继续维护和扩展的重复模式。

Demo 与生产系统采用的是两套验收标准

Demo 通常运行在理想条件下：输入经过挑选、数据提前准备、流程只有一条正确路径，开发者还可以随时介入。真实业务则充满缺失信息、模糊需求、权限差异、系统超时、政策例外和意外行为。

很多团队把回答正确率、生成效果或工具调用成功当成最终指标，却没有验证工单是否真正解决、记录是否正确写入系统，或者员工是否愿意持续使用。Agent 产出了内容，并不等于流程完成了。

• 没有接入真实数据、权限和业务系统，Agent 只能停留在聊天窗口。
• 没有覆盖异常路径的评估集，团队只能在生产投诉出现后被动修补。
• 没有重试上限、人工审批和升级路径，所谓自主就会变成不可控。
• 没有流程负责人和持续采用机制，技术上线也无法进入日常工作。

从 Demo 走向生产需要补齐完整闭环

生产部署需要先定义业务结果和成功标准，再连接系统、编码权限与升级规则，运行真实案例和异常案例评估，进行受控上线并监测最终业务状态。Anthropic 也强调，Agent 的评估不能只看它声称完成了什么，而要检查真实或沙箱环境里的最终状态是否真的改变。

先判断这个流程是否值得且适合使用 Agent

一个好的起点应当高频发生，并且当前流程需要大量人工查找、复制、判断、等待或交接。发生频率越高，单次改善越容易累积成可见价值。

OpenAI 建议优先关注需要结合上下文判断、规则复杂且难以维护、严重依赖文档或自然语言等非结构化数据的工作。如果任务完全由稳定规则决定，普通软件或传统自动化往往更便宜、更可靠。

• 业务价值：是否高频、耗时、积压，并影响客户或关键团队。
• Agent 适配度：是否包含多步骤判断、异常和非结构化信息。
• 可验证性：能否明确判断任务是否完成、质量是否合格。
• 就绪度：真实数据、工具接口、权限和流程负责人是否可获得。
• 风险边界：错误是否可发现、可撤销，敏感动作能否要求人工审批。
• 推广条件：是否有真实使用群体以及愿意对结果负责的业务负责人。

从真实工作开始，而不是从 Agent 技术开始

典型的第一个场景可以是内部工单的理解、资料收集、处理建议和分派，也可以是高频文档审核中的信息提取、风险提示和初稿生成。它们的共同点不是简单，而是流程清楚、数据可取、结果可查、人工可以接管。

价值必须通过完整因果链传导

一个 AI 项目要影响营业结果，必须形成完整链条：Agent 产出改变人的行动，人的行动改善流程瓶颈，流程改善最终推动客户、收入、成本或风险指标变化。只要其中一环断开，局部效率就不会自然变成业务价值。

• 自动化了非瓶颈环节：报告生成更快，但仍然等待两周审批。
• 节省了执行时间，却增加审核、核对和返工，流程总成本没有下降。
• 把系统复杂度当成价值，不断增加工具和 Agent，反而增加延迟、成本和失败点。
• 把演示参与、注册或第一次试用当成采用，没有观察真实工作的重复使用。

用结果约束项目范围

Anthropic 建议先寻找能够满足需求的最简单方案，因为 Agent 系统通常以更高延迟和成本换取任务表现；只有简单方案确实不足时，才应增加多步骤或多 Agent 架构。

每个项目都应该明确一个优先流程、一个结果指标、一个业务负责人和一条证据链。与其同时多做一些，不如先确认 Agent 的产出会改变谁的什么行动，以及下游流程能否承接增加的产能。

不要只看调用量，要同时收集五类证据

调用量只能说明系统被打开过，不能说明流程已经改变。真实评估需要同时观察采用、效率、质量、安全和最终业务结果。

• 采用：是否进入真实工作，符合条件的任务有多少实际使用，用户是否重复使用。
• 效率：端到端周期、人工操作时间、等待、交接、返工和相同人力下的处理量。
• 质量：首次通过率、错误率、遗漏率、返工率和人工修改幅度。
• 安全：失败任务、越权尝试、错误工具调用、重试、人工升级和重大异常。
• 业务结果：积压、响应时间、转化、客户体验、回款周期或风险损失是否改变。

按合格完成的任务计算真实单位成本

单位成本应当等于模型与工具、基础设施、运维、人工审核、返工升级和失败损失的总和，再除以通过质量标准并真正完成业务目标的任务数。分母不能使用 Agent 运行次数，否则低价但大量失败的系统会被错误判断为高效率。

评估可以使用同期对照、分批上线或上线前后比较，但样本需要覆盖日常任务与典型异常，并保持相同质量口径。更快不自动等于更好；如果生产时间下降但审核与修正增加，两部分都必须计入。

隐性经验必须转化为显性规则

员工知道应该去哪个群里询问最新口径、哪个系统的数据不能完全相信、谁可以批准例外，以及制度没有覆盖时该如何处理。这些知识往往没有真正存在于流程或数据系统里，而是分散在个人经验和长期形成的默契中。

• 流程问题：步骤因人而异，开始和结束条件不清楚，职责重叠，异常处理没有记录。
• 数据问题：信息分散在多个系统，同一指标存在多个定义，数据过期或缺少关键字段。
• 权限问题：系统权限与实际职责不一致，无法说明 Agent 可以读取、修改或批准什么。
• 评估问题：没有完成条件、权威来源和异常样本，无法判断 Agent 是否做对。

把暴露问题当成一次组织压力测试

Agent 不仅生成内容，还可能跨系统连续行动。一个错误字段会影响后续判断，一项模糊规则会在多个步骤中持续传播，一次权限配置错误则可能扩大为真实业务风险。

企业应先记录真实发生的流程，明确输入、输出、负责人和完成条件；再确定权威数据源、统一关键字段，按最小权限设置操作与审批范围；最后把真实异常整理成测试案例和升级规则，从小范围受控上线开始持续修正。