Agent 到底什么时候该用FDE 如何设计一个生产级 AI Agent专栏《AI FDE 实战从 Demo 到生产》第 12 篇 / 共 18 篇本篇目标为模型的自主行动划定可执行的边界让一个多步骤任务能够暂停、恢复、停止并留下可核验的结果。本篇产物一份 Agent 选型方法、一套有界状态工作流以及能够离线运行的 SQLite 教学实验。星河设备的内部售后助手已经能够查保修政策、读取授权订单并生成工单草稿。业务负责人开始提出新的期待“既然这些能力都有了能不能让它自动把整件事情办完”这里的“整件事情”可能意味着确认用户所说的设备型号查找适用政策读取订单检查材料是否齐全生成工单等待客服确认再把处理结果告诉客户。某些任务三步就能结束某些任务要追问两次还有一些任务必须交给主管判断。这确实进入了 Agent 的讨论范围但我们还不能立刻得出“需要多 Agent 框架”的结论。首先应当确定哪些选择允许模型作出哪些步骤必须固定哪些事情只有人能批准以及任务失败后由谁接手。本篇继续使用虚构的星河设备、XH-200、订单 SO-1042 和内部售后流程。所有政策、指标与业务数据均为教学设定。随文代码只使用本地模拟数据不调用真实模型不连接真实 CRM也不代表生产系统已经通过认证。一、先判断问题是否真的需要 Agent“能调用工具”与“需要自主规划”是两件不同的事。一个程序依次执行数据库查询、文档检索和结果渲染即使中间使用了大模型也可以是普通的固定工作流。相反当程序需要根据刚得到的证据决定下一步要查什么、是否换一个方向、什么时候停止时模型才开始承担动态决策责任。Anthropic 在工程文章中区分了工作流与 Agent前者主要沿预定义路径编排模型和工具后者由模型动态决定过程中的行动。这是理解架构边界的有用分类并不是统一的行业认证标准。来源Building effective agents对星河设备可以先把需求分成三类。第一类是明确的查询。“订单 SO-1042 是否已发货”需要身份校验、对象授权、业务接口调用和结果展示。路径很明确让模型反复思考下一步只会增加延迟和错误机会。模型可以负责理解用户输入真正的查询仍然由确定性代码执行。第二类是有限分支任务。“帮我整理这个订单的保修申请材料。”它可能需要补充型号可能发现订单不存在也可能已经有足够信息。分支数量有限规则能够写清适合有明确状态的工作流。模型可以在状态内部整理语言或提取候选字段而不拥有任意跳转的权力。第三类是开放调查。“分析最近这批设备退货的主要原因并指出还缺哪些证据。”事先不容易确定要看几份材料、比较多少订单以及是否需要继续调查。此时可以考虑让 Agent 在只读工具集合中动态选择下一步但仍要限制数据范围、运行预算与报告责任。一个实用的判断方法是问自己如果把模型换成一位经验不足的实习生我是否愿意把同样的工具与权限交给他并在同样长的时间内不查看过程如果答案是否定的问题通常不是模型还不够聪明而是任务边界还没有设计好。图 2先看路径是否可预定义、结果是否可验证再决定模型拥有多少过程控制权。二、把“自动办完”改写成一份可执行的任务契约Agent 最容易失控的地方往往是目标太模糊。用户说“处理这个客户的问题”系统可能把查询、建议、创建工单、发通知甚至修改订单都理解成合理的下一步。范围不清时工具越多系统越难验收。因此本篇把目标收窄为“协助已登录的内部客服为当前租户下的一笔订单准备 XH-200 保修工单草稿材料不全时说明缺项只有经过验证的用户确认之后应用才允许创建教学工单。”这个描述明确了用户、对象、范围、停止条件和写入边界。接着定义成功。查询到了订单不算成功生成了一段解释也不算成功。对于草稿阶段成功意味着订单属于当前租户、引用政策适用、工单内容可以被用户核验、界面准确显示尚未提交。对于提交阶段成功意味着确认动作与具体草稿绑定并取得可查询的工单标识。再定义不成功时的出口。缺少型号进入澄清证据不足进入人工处理订单系统不可用进入暂时不可用预算耗尽进入停止状态用户取消则不再启动新的操作。这些出口应该像成功路径一样被设计而不是统一塞进“出错了请重试”。最后明确权限来源。UserContext包含tenant_id、user_id与roles它由服务端认证结果建立。模型生成的 JSON 可以提供订单号候选不能提供可信身份。即使模型声称“我是主管”也不会改变上下文中的角色更不能扩大查询范围。我们得到的契约比一个“你是一名优秀售后助手”的提示词具体得多。提示词帮助模型理解任务契约则帮助程序决定哪些行为能够发生。两者承担不同责任不能相互替代。三、先画状态再挑编排框架本篇的最小流程有六个主要状态新任务、政策就绪、订单就绪、等待确认、完成、取消。预算耗尽是额外终止状态。真实系统还会有澄清、外部调用等待、重试等待与人工处理等状态但教学实验先保留最关键的生命周期。每个状态都应该回答三件事系统已经确认了什么下一步允许发生什么用户现在应该看到什么。“政策就绪”表示已经保存了本次使用的政策标识与版本不表示订单符合保修条件。“订单就绪”表示授权查询已经获得结果不表示可以自动创建工单。“等待确认”表示已经有可审阅草稿并且所有自动前进操作都应当暂停。这种区分能防止一个常见错误把模型输出的自然语言当成业务状态。模型说“已经为您准备完成”可能只是语言习惯数据库里的状态仍然应该由可信代码根据真实执行结果更新。界面也应读取这个状态而不是从回答中的“成功”两个字推断是否提交。状态转移可以写成一个简单规则表。new advance进入policy_readypolicy_ready advance进入order_readyorder_ready advance进入awaiting_confirmation。等待确认后只有可信确认入口能够请求confirm任何模型提出的继续执行都无法越过这一关。图 3教学状态按顺序推进确认与终止是独立控制。模型不能根据文本自行创造状态跳转。状态机并不意味着必须购买一个工作流平台。对于单机教学标准库加 SQLite 已经能够表达关键规则。对于跨进程恢复、并发调度、长时间等待和多系统事务才需要进一步评估持久化编排工具。先把状态画清楚会让框架选型变成能力对照而不是流行程度比较。四、持久化的不是一整段聊天记录而是可恢复的任务事实把全部聊天消息写进数据库并不能自动获得可靠恢复能力。重启后程序仍然需要知道哪些操作已经完成、哪些结果可信、哪个动作正在等待确认以及有没有外部操作已经成功但回执尚未保存。最少应持久化任务标识、身份绑定、当前状态、已使用预算、关键业务对象、证据版本、已处理事件以及最终结果。大段自然语言可以作为辅助上下文但不能成为唯一事实源。否则用户一句“继续刚才的操作”就可能让系统重做已经发生的写入。在实验中runs表保存任务状态与教学负载events表保存已经处理的事件tickets表保存创建结果。订单与政策都使用固定模拟数据因此没有外部网络副作用。我们可以把任务状态、事件记录和工单创建放在同一个数据库事务里提交。真实 CRM 不在这个事务里问题就不同了。假设调用 CRM 成功后进程在写入本地结果之前崩溃。恢复程序看到的是“未完成”再次提交就可能产生两张工单。解决办法通常需要上游支持幂等键或者使用可查询的业务请求标识与对账过程单纯给本地函数加一次重试并不能解决。持久化编排框架也不会让所有外部副作用自动变得安全。使用检查点时需要理解哪些节点可能重放把外部动作设计成幂等操作并记录足够的完成证据。LangGraph 的持久化文档展示了检查点与恢复相关能力具体可靠性仍取决于节点实现与存储配置。来源LangGraph Persistence还有一个容易被忽视的问题恢复时身份可能已经变化。昨天客服可以处理这笔订单今天账号被停用昨天的政策版本适用今天业务负责人撤回了某个例外。恢复任务不能只因为数据库里有旧上下文就无条件继续。生产接入需要重新验证当前权限并决定是否要求用户重新审阅已变化的草稿。五、预算要在调用前生效不能只在账单出来后统计很多 Agent 演示只设置一个最大循环次数。这个限制有用却不足以覆盖生产成本。一次循环可能只做一次短查询也可能并行发起多个模型请求、读入大量文档并产生很长输出。因此步数只是预算的一种维度。星河设备至少可以考虑四类预算执行步数、外部请求次数、累计等待时间、模型消耗上限。对于长任务还应区分单个工具的超时与整个任务的截止时间。某个接口每次都在自己的超时范围内返回也可能让整个任务持续得远超用户可接受范围。预算检查应该发生在启动下一次操作之前。若本次调用可能超过剩余预算就提前缩小范围或停止。调用返回后再记账是核算调用之前根据剩余额度决定能否继续才是控制。对模型消耗而言实际计费可能需要事后结算所以还要保留估算误差的余量。实验只实现最大自动推进步数并明确不把它称为完整成本控制器。每次advance之前检查step max_steps达到上限后转为budget_exhausted不会再执行新的业务步骤。确认和取消不消耗自动推理步数因为它们属于人的控制动作。预算耗尽后的用户体验也值得设计。系统应告诉用户已经得到什么、还没有完成什么以及如何转交人工不能一边显示“任务失败”一边丢失已经整理好的可用草稿。保存部分成果可以减少返工但展示时必须标记它们仍未完成验证。图 4本地事务可覆盖同一数据库中的状态与工单。外部服务另需幂等与对账设计。六、人的确认要确认具体对象不能只确认一句“继续”“是否允许 Agent 继续”是一个过于宽泛的问题。用户不知道接下来会创建什么、影响谁、内容是什么也不知道这个批准是否会被重复使用。真正可用的确认应该针对明确动作与明确草稿。在工单场景中确认界面至少应该展示订单、客户对象、问题摘要、附件清单、政策依据以及提交后的后果。用户修改草稿之后确认必须绑定修改后的版本。旧版本的确认不能被拿来提交新内容否则用户看到的与系统执行的会出现差异。本篇实验没有网页因此用可信应用代码调用confirm来代表用户确认。这里的“可信”是一项接口契约未来接入 FastAPI 时确认入口必须先验证登录状态、资源归属、当前权限与草稿版本不能直接把聊天文本映射成确认事件。confirm_ticket也不应成为模型可自由调用的工具。OpenAI 的 Agent 安全文档建议在敏感工具操作中保留审批、限制不可信输入的影响并使用结构化的数据流降低风险。这些建议说明了应用控制的重要性但不能替代企业自身的对象授权与业务验收。来源Safety in building agents取消也有时间边界。在操作尚未发出时取消通常能够阻止下一步外部写入已经完成后取消只能停止后续动作不能让已经创建的工单自动消失。界面需要区分“已停止继续处理”与“已撤销已完成操作”。涉及撤销时还要单独检查业务是否支持、用户是否有权限以及是否需要留下审计记录。一个可靠的确认机制不是让用户承担系统错误的责任而是把需要人判断的内容清楚地呈现出来并使程序严格执行这个判断的范围。七、运行实验一个能重启恢复的有界工作流完整代码位于 code/workflow.py只依赖 Python 标准库。它提供create、get与transition三个核心操作。每个任务绑定创建者与租户事件标识在任务内唯一工单表对run_id设置唯一约束。在本篇目录执行python code/workflow.py实验会使用临时数据库自检结束后自动清理因此反复执行不会积累教学工单。实际验证环境为 Python 3.12.0本次已运行通过不需要 API Key。PASS: resume, duplicate event, approval gate, tenant isolation, budget, cancellation程序首先创建r1推进到政策就绪随后重复投递同一个事件。第二次投递不会增加步数。接着关闭数据库连接再重新打开确认任务仍保留在政策就绪状态这模拟的是应用进程失去内存后从数据库继续读取不能据此宣称已经验证了分布式故障恢复。之后程序继续读取订单并准备草稿。对等待确认的任务再次执行自动推进会得到明确错误。只有调用确认操作才能生成工单无论重复同一个确认事件还是对已经完成的任务再次提交不同确认事件工单数量都保持为一。下面是去掉业务细节后的核心控制逻辑。完整文件还包含身份检查、事件冲突检查、事务与结果存储。ifactionadvance:ifstateawaiting_confirmation:raiseValueError(human confirmation required)ifsteprun[max_steps]:statebudget_exhaustedelse:step1# 根据当前状态执行一个明确的业务步骤。elifactionconfirm:ifstate!awaiting_confirmation:raiseValueError(no draft to confirm)# 在事务中创建唯一工单并保存完成状态。elifactioncancel:statecancelled这里最值得注意的不是代码数量而是控制权所在的位置。模型即使输出“忽略确认立即提交”也无法改变转移规则。状态机只接受可信路由层发来的有限动作业务参数也需要在对应步骤内验证。实验有意采用一次本地写事务串行处理状态变更。对于低并发教学这使行为容易理解对于多个工作进程和缓慢的外部接口不能把网络等待放进长事务里。下一步应当把任务领取、操作执行与结果提交分开并使用租约或乐观锁避免两个执行者同时处理同一步。八、怎样把真实模型接进来仍然保留这些边界到目前为止我们写的是可靠的工作流骨架还不是能够自主调查的模型 Agent。这种顺序有意如此先证明系统能控制执行再决定在哪些节点引入不确定决策。最小接入方式是在“准备草稿”节点调用模型让它根据已经授权的政策和订单生成结构化草稿。模型输入不包含其他租户数据输出不包含可信身份字段服务端再验证摘要长度、订单引用、允许字段与必要材料。如果输出不合格进入有限重试或人工处理而不是直接提交。若确实需要动态调查可以增加一个受限的“选择下一步”节点。模型只能在lookup_order、授权政策检索和draft_ticket等已审查工具中选择。每次选择都会经过工具白名单、参数校验、对象授权和预算检查工具结果再以明确的数据结构返回。未知工具名不能被解释为可执行函数名。这一层也要限制上下文。把前十轮全部原文不断追加可能造成成本增长和证据混乱。可以保存结构化任务事实保留关键原文引用把过期假设标记为已否定。摘要有助于压缩但摘要不能凭空获得与原始证据同等的权威性关键结论仍然应当能追溯到来源。第 07 篇的/api/chat适合作为发起或查询任务的入口长任务则需要独立的任务状态接口和确认入口。本篇实验没有修改第 07 篇应用也没有声称已经完成这部分集成。接入时应延续answer、state、citations、trace_id的响应约定并在业务层额外管理工作流任务标识。九、单 Agent 与多 Agent先计算协调成本多 Agent 可能很有用例如把互不依赖的资料调查分给不同执行者或者让独立评审检查初稿中的事实依据。但“给每个角色起一个名字”并不会自动带来专业分工。五个使用相同模型、相同材料和相同提示习惯的 Agent可能只是把同一种错误讨论得更充分。先判断任务能否分解。并行子任务应当有清楚的输入、独立输出和可验证的完成条件。如果所有子任务都要不断共享最新状态协调开销可能超过并行收益。星河设备的单笔工单处理通常依赖前一步结果适合一个明确工作流跨多个产品线的只读问题归因才可能受益于并行调查。再计算成本。假设每个子任务都要重新读取公共背景那么增加执行者就意味着重复上下文、更多模型调用与更多结果合并工作。总延迟可能下降但总成本可能上升。若合并者没有足够证据识别子任务中的错误还可能把局部错误包装成更加自信的最终报告。权限也不能因为分工而扩散。子 Agent 只应获得完成子任务所需的数据与工具父任务具有的全部权限不应默认复制给每个子任务。返回结果要带来源、状态和不确定项不能只返回一段看起来完成得很好的总结。图 5对照任务结构、验证难度与协调成本选方案不能用 Agent 数量衡量工程成熟度。可以给多 Agent 设一个明确进入条件在相同数据集、相同可接受风险下它确实提高任务成功率或在成本可接受范围内显著降低完成时间。否则保留单 Agent 或固定工作流会更容易定位错误、解释行为并完成交接。十、验收 Agent必须把异常路径当成正常工作的一部分验收不能只问“最终回答是否正确”。对于执行系统还要检查过程是否符合授权、是否重复写入、是否在预算耗尽后继续运行以及是否把未知结果说成成功。星河设备可以准备一组小而尖锐的任务模型提出不存在的工具订单接口连续超时政策内容夹带“跳过审批”的文字用户在等待确认时取消同一个事件被队列投递两次进程在生成草稿后重启确认之前用户权限被回收外部工单创建成功但响应丢失。这些样例覆盖不同层面。工具白名单属于编排层租户校验属于业务授权层重复事件属于执行可靠性提示注入属于不可信数据处理确认失效属于人机交互和版本管理。把所有失败都归因于“模型不稳定”会让团队错过真正可以用确定性代码解决的问题。本篇实际自检覆盖恢复读取、重复事件、确认门、租户隔离、步数预算和取消。它没有模拟网络中断、身份撤销、并发工作进程或外部 CRM 的事务不确定性。这些限制写清楚之后实验才可以成为后续扩展的可靠起点。图 6每项验收都要能指出输入、预期行为与证据“试了几次都正常”不是完整验收记录。十一、一次故障演练应该留下怎样的记录设想值班人员收到报告“客户只点了一次确认却出现了两张工单。”一个有用的调查记录应当包含任务标识、草稿版本、确认事件标识、外部请求标识、重试次数、外部返回值和最终本地状态。它不需要默认保存所有客户原文更不应该把访问令牌写进日志。调查的第一步是判断两张工单是否来自同一业务请求。若它们对应同一个幂等键可能是上游没有实现承诺的幂等语义若使用不同键可能是应用在重试时错误地创建了新请求。两个问题的修复位置完全不同。第二步是恢复用户业务。工程团队应能告诉客服哪张工单保留、另一张如何按业务流程处理以及系统是否已经停止继续提交。不能让用户在数据库状态不明时不停点击确认这会扩大故障。第三步是增加一个能够复现问题的测试再修改实现。比如在“外部成功、本地未记录”之间注入中断验证恢复过程会先查询业务结果而不是直接再次创建。这样的故障样例比增加一句“不要重复提交”的提示词更有价值。最后把事故带回任务契约。如果某类操作没有可查询的外部请求标识或者无法判断是否成功就应当限制自动重试进入人工核对。系统诚实地停在不确定状态通常比冒险把结果补成“成功”更有利于实际交付。十二、实战练习让系统学会正确地停下来先运行随文代码读懂每个断言对应的业务承诺。然后做三个扩展不必一次完成所有生产功能。第一个扩展是增加“缺少序列号”状态。让草稿节点发现必要字段为空时进入needs_clarification保存具体缺项并要求后续补充只能更新允许字段。验收时检查用户补充一个无关字段不会让任务自动进入提交。第二个扩展是加入草稿版本。用户每次编辑生成新版本确认请求携带所审阅的版本号。服务端发现版本不一致时拒绝提交并返回当前草稿供重新审阅。这个练习能帮助你理解“确认过”为什么不是一个永久有效的布尔值。第三个扩展是模拟外部接口结果不确定。在本地字典或独立教学表中模拟外部工单系统让它支持稳定的请求标识。故意在外部成功后抛出异常再恢复任务确认最终仍然只有一张工单。只有这一步经过验证才有资格讨论把同一策略应用到真实接口。每做一个扩展都写下新增状态、允许动作、终止条件与一条失败测试。不要先增加复杂框架再寻找它能解决的问题。状态足够清楚时更换实现工具会相对容易状态含糊时再好的框架也只是把含糊执行得更快。FDE Thinking为什么这里没有直接写一个无限工具循环因为星河设备当前最需要的是可靠完成有限业务任务。动态规划只有在路径确实无法合理预定义时才带来额外价值而预算、授权、恢复和确认始终由应用承担。什么时候值得把固定节点升级成 Agent当真实失败样例表明预定义路径无法覆盖合理任务而且我们能够验证动态行动的结果。升级的理由应该来自任务数据不能只来自演示效果或技术潮流。怎样判断系统已经接近可交付不仅要看成功时完成了多少步骤还要看失败时是否停在明确状态重启后能否继续重复请求是否产生重复结果以及接手的人能否根据记录理解已经发生的事情。生产级 Agent 的核心能力之一是知道何时继续、何时请求人的判断、何时停止。把这三种行为写进可执行系统才是 FDE 把模型能力转化为业务可靠性的关键工作。