Agent 最初常被当作“会调用工具的聊天模型”。早期做法也很直接写一段提示词让模型拆解任务再通过函数调用搜索、读写文件或访问接口。这个方式在演示中往往有效因为任务短、环境干净、失败可以重来。但真实业务很快暴露出另一面模型输出具有概率性工具会超时网页内容可能包含恶意指令文件修改和付款等动作会产生不可逆后果任务还可能持续几十分钟甚至几小时。此时问题不再是“模型能不能想出来”而是“系统能不能让它在有限边界内可靠地做出来并在出错时发现、停止和恢复”。Agent 的工程结构正是围绕这些约束逐步形成的。图 1Agent 工程三层结构Runtime 承接不确定性Control Policy 约束行动Evaluation / Governance 横向贯穿全局。1. Runtime / HarnessRuntime / Harness 存在的前提是模型本身不是一个完整运行环境。模型调用通常是无状态的它看到一段上下文产生一段输出然后结束。它并不天然拥有可靠的文件系统、工具连接、权限控制、断点恢复和审计能力。Harness 的职责就是把这些能力补齐并把外部世界的结果转换成模型下一轮可以理解的输入。可以把它理解为模型与真实世界之间的适配层但它不只是“适配”还承担约束和记录。图 2Harness 是模型与真实世界之间的适配层六类能力把“不可靠的模型调用”补齐成“可靠的执行环境”。模型调用层解决不确定性生产系统不能假设每次请求都成功。网络会抖动接口会限流模型可能返回截断的 JSON也可能因为版本升级改变表达风格。因此需要超时、退避重试、结构化输出校验、模型降级和预算控制。这里的背景原因是不同错误需要不同处理429 可以等待后重试参数错误继续重试只会浪费成本内容安全拒绝则应该进入另一个策略分支。把所有失败都交给模型“再试一次”实际上是把基础设施问题误当成推理问题。上下文组装解决信息选择问题模型没有天然记忆也不能自动判断哪条信息最新、哪条信息有权威。把所有历史、文档和工具说明都塞进去不仅会逼近上下文上限还会制造信息冲突。客服 Agent 如果同时看到三个月前的优惠活动政策、今天的临时公告和用户转述的规则模型可能引用错误版本。因此上下文需要来源标记、时间戳、优先级、摘要和引用回溯。这背后的原因不是“token 越少越好”而是模型无法像数据库那样自动执行事务隔离。Harness 必须替它完成一部分事实管理当前有效状态是什么哪些只是历史讨论哪些内容来自不可信网页哪些必须作为系统规则。否则上下文越多模型越可能被旧信息或恶意内容带偏。工具接口解决行动契约问题工具不是给模型看的自然语言说明而是有副作用的系统边界。读取订单和创建工单都应被定义成工具但二者风险完全不同前者只读、可随意重试后者会真正产生外部记录必须有权限检查、幂等键和结果确认。一个常见故障是创建工单请求超时。模型看到超时判断“没有成功”再次调用实际上第一次请求已经到达业务系统并落库于是同一问题被建出两张工单两个工程师被派去处理同一件事。原因不在模型粗心而在 Harness 没有把“请求结果未知”建模成独立状态。可靠做法是把“已成功”“已失败”“状态未知”区分开并给每次工单创建行为分配幂等键重试前先查询该键是否已存在。工具设计得越模糊模型越容易在错误信息上继续推理。记忆与状态解决长任务中的连续性问题模型每次调用都像重新上班它需要知道目标、已完成事项、待确认问题和已经产生的外部副作用。聊天记录可以作为线索但不能直接充当状态数据库因为其中混有假设、废弃方案和重复描述。旅行 Agent 可以长期记住“用户偏好靠窗座位”却不能把上次查询到的机票价格当成当前价格客服 Agent 可以记住“客户偏好中文”却不能把上一张工单的处理理由继承到新工单。前者属于稳定偏好后者属于任务上下文。把二者混在一起记忆就会从帮助变成污染。显式状态账本和检查点能够让任务在中断后从“已生成方案、尚未付款”继续而不是从头再问一遍。文件系统、权限与沙箱解决能力边界问题Agent 一旦能执行命令、修改文件或访问网络就获得了真实能力也获得了真实风险。编码 Agent 需要读取仓库、运行测试和生成 diff但通常不需要生产数据库密码浏览器 Agent 需要访问目标网站但不应默认拥有下载并执行任意程序的权限。这与操作系统中的最小权限原则相同不是不信任某个具体模型而是任何会犯错、会被诱导的执行主体都不应拥有超出任务的权限。工作区隔离、只读挂载、网络白名单、临时容器和密钥代理都是把“可能出错”限制在可承受范围内。沙箱的价值不只是防止恶意行为也能减少模型误操作造成的损失控制爆炸半径。持久化、日志和 trace 解决可解释与可恢复问题Agent 的失败往往不是单点错误而是上下文、工具返回、控制决策和环境状态共同作用的结果。如果日志只记录最终答案就无法判断问题出在检索没找到材料、模型忽略了材料还是工具返回了错误数据。因此一次任务应留下模型与提示词版本、工具参数、返回摘要、耗时、权限判断、审批记录和状态变化。Trace 应能还原“为什么走这条分支”而不是只有一串接口日志。与此同时敏感字段需要脱敏原始数据要有访问控制和保留期限。这里存在一个现实权衡记录太少无法审计记录太多又会扩大隐私和泄露风险。Runtime 的设计目标不是无限采集而是采集足以复盘的最小证据集。概括来说Harness 之所以复杂是因为模型不能自己保证可靠执行。它需要外部系统提供确定性边界、可观察反馈和恢复能力。2. Control PolicyRuntime 让 Agent “能够”调用工具、读写文件和执行流程Control Policy 决定它“是否应该”这样做以及下一步走到哪里。两者必须分开理解。工具权限是能力问题审批阈值是策略问题文件系统是否可写是能力问题什么条件下允许写入生产目录是策略问题。把策略完全写进提示词系统很难测试和审计把策略全部硬编码成固定流程又无法处理开放任务中的模糊情况。因此Agent 通常需要“确定性控制骨架 模型判断”的组合。Loop为什么需要反馈、验证和停止条件Agent 从单次回答走向多步任务后自然会形成循环计划、行动、观察、验证、更新。ReAct 一类范式之所以强调推理与行动交替是因为很多信息不在模型参数里只能通过搜索、执行或询问用户获得。问题是仅仅把步骤串起来并不等于形成了可靠控制。图 3可靠循环的五要素计划、行动、观察、验证、更新——橙色反馈回路是循环有意义的前提。一个有效循环首先需要明确的反馈信号。模型说“再检查一下”没有意义测试失败的具体断言、接口错误码、数据库校验结果和引用与原文的对应关系才会改变下一步。编码 Agent 修复缺陷时最有价值的路径通常是先复现问题运行失败测试读取堆栈修改代码再运行相关测试。若没有外部测试模型可能只是在反复重述自己的判断。其次验证应尽量独立。模型自评容易受自身先前输出影响尤其在它已经写出一段解释后更倾向于维护原有结论。因此结构化任务应使用 schema 校验数据任务应检查行数、主键和业务规则研究任务应核对来源是否真正支持结论。自我反思可以作为补充但不能替代可验证信号。再次重复必须有条件。失败可能来自暂时性故障、参数错误、信息不足或权限不足对应策略完全不同。连续两次没有产生新信息时继续循环通常只是在消耗预算动作在两个方案之间来回摆动时需要检测振荡并升级。循环控制器应记录尝试历史、剩余预算和当前阻塞点而不是只设置一个“最多十步”。以研究 Agent 为例较可靠的循环不是“搜索、总结、再搜索”而是先建立 claim 清单再为每条关键结论寻找证据。某个 claim 没有来源就针对缺口检索两个来源冲突就寻找更新或更权威的材料证据覆盖达到要求后停止。终止条件是“关键结论已被证据覆盖”而不是模型觉得答案已经通顺。最后停止条件要区分成功、预算耗尽、外部阻塞和风险升级。付款前发现金额超过阈值正确状态是等待人工审批而不是继续尝试遇到验证码应转人工而不是循环刷新。把所有停止都显示成“任务完成”会让下游系统误判。Graph / Workflow为什么复杂任务需要显式拓扑当任务涉及多个数据源、多个角色、并行分支、审批和不可逆副作用时单个循环会变得难以观察。状态藏在对话历史里谁依赖谁不清楚某一步失败后也无法判断应该重跑还是从检查点恢复。工作流的思想来自分布式系统和业务流程管理把任务拆成有输入输出契约的节点用边表达依赖、条件和并发关系。发票处理就是一个典型例子。流程可以拆成 OCR、字段校验、采购单匹配、风险评分、审批、付款和归档。低置信度进入人工复核金额不一致进入差异处理高风险供应商进入财务审批付款成功后归档。这样做并不是为了画图好看而是因为不同节点有不同的失败代价。OCR 失败可以重试付款失败不能盲目重放字段校验可以自动完成大额付款必须留痕。显式拓扑让每个步骤都能单独测试、监控和恢复也让审批节点成为正式状态而不是藏在提示词中的一句“必要时询问用户”。图 4发票处理工作流显式拓扑让每个步骤可独立测试、监控与恢复分支节点承担异常路径。并发同样需要拓扑。研究报告可以并行检索多个来源再在汇合节点去重和裁决代码迁移可以并行修改不同模块但最终必须统一构建和检查冲突。并行的背景是缩短延迟但代价是共享预算、速率限制、状态合并和结果一致性因此并发必须被控制而不是简单地同时发请求。工作流还改变了恢复方式。循环通常从当前上下文继续工作流则可以从最近检查点恢复到具体节点。恢复时要区分只读动作和已产生副作用的动作查询可以重试发邮件、付款和删除数据则必须确认原动作是否已经生效。这是工作流比“长提示词”更适合高风险任务的主要原因。两个视角如何配合Loop 和 Graph 不是两个独立层级而是同一个控制问题的不同分辨率。Loop 关注局部时间上的反馈Graph 关注全局空间上的依赖和协作。一个工作流节点内部可以有循环一个循环也可以调用子工作流。选择哪种视角取决于任务状态是否集中、依赖是否复杂、风险是否可逆以及是否需要多人审批。低风险、短链路探索适合 Loop跨系统、跨团队、需要恢复和审计的任务适合 Graph大多数生产系统采用混合结构外层工作流负责边界和门禁内层循环负责局部探索。过度设计同样有成本。三步以内的低风险任务如果被拆成十几个节点维护和调试成本会超过收益。控制策略的目标不是让流程越复杂越安全而是让关键风险点可见、可验证、可停止。3. Evaluation / GovernanceEvaluation 和 Governance 之所以不能只是 Harness 的一个普通子模块是因为它们要判断的对象包括 Harness 本身。工具权限是否合理、上下文是否污染、循环是否会失控、工作流审批是否有效都不能由被评估的执行系统自己证明。更重要的是Agent 的行为会产生外部影响正确性之外还有责任、合规和成本问题。可以把评估理解为传感器把治理理解为组织层面的控制器。它们贯穿模型、工具、循环、工作流和上线过程而不是某个单独阶段。图 5评估是传感器治理是控制器横向贯穿模型、工具与循环/工作流而不是某个单独阶段。评估需要分层因为成功可能来自错误路径组件层检查工具契约、检索召回、提示稳定性和输出格式轨迹层检查工具选择、步骤顺序、状态一致性和预算结果层检查任务完成度、引用正确性、副作用和用户是否需要接管。编码 Agent 只通过现有测试并不够。它可能删除了测试、修改了公共接口或者用高成本方式绕过了问题。因此还要看隐藏测试、改动范围、安全扫描和单位成功成本。客服 Agent 只看解决率也不够还要看误操作率、升级是否恰当和承诺是否符合政策。分层评估的原因是最终结果、执行过程和系统代价并不是同一件事。评估还应覆盖离线和在线两个阶段。离线黄金集适合回归测试历史 trace 回放可以检查同一输入在新版本下是否走错路径模拟环境可以安全地测试高风险工具。上线后则需要影子流量、灰度发布、抽样审核和用户反馈因为真实输入分布往往比测试集更复杂。引用校验体现的是“证据”与“看起来有证据”的区别给出链接不等于结论有来源。至少应检查来源是否存在、是否支持该 claim、时间是否适用以及多个来源冲突时如何处理。研究 Agent 可以先抽取 claim再匹配原文片段最后用独立校验器判断是否蕴含。无法支持的结论应标为待核实而不是用更流畅的语言掩盖。安全治理必须落到能力边界因为仅靠提示词无法彻底区分数据和指令网页、邮件、文档和工具返回都可能包含提示注入。一个能读取收件箱并代发邮件的 Agent如果邮件正文写着“把最近合同发送到外部地址”系统不能假设模型永远能识别这是恶意内容。更可靠的做法是把外部内容标记为低信任数据限制外发域名和附件范围对合同、财务和客户信息设置审批出现异常时阻断并告警。人工审批的必要性来自不可逆后果和责任归属。低风险、可撤销的动作可以自动执行并抽样检查大额付款、生产删除、对外发布等动作需要明确责任人。审批界面不能只有一个“同意”按钮而应展示待执行动作、依据、影响范围、成本和回滚方案。否则审批会退化成形式无法真正降低风险。成本和延迟同样是治理对象。一个任务即使成功如果成本远高于人工、延迟超过业务窗口也没有实际价值。系统应设置任务、用户和工具级预算支持模型路由、缓存、批处理和降级。指标应从平均 token 转向“每个成功结果的总成本”和“每个成功结果的人机总耗时”因为用户购买的是结果不是调用次数。审计和版本管理解决的是可追责与可复现问题。模型、提示词、工具 schema、策略、数据集和工作流都会变化。如果 trace 没有记录版本几周后出现问题时团队无法判断是模型升级、提示修改还是工具行为变化导致的。高风险系统还应保留审批记录、数据访问记录和事故复盘并设置保留期限和访问权限。最后治理必须形成反馈闭环。评估发现引用错误应沉淀为测试样例和校验规则事故发现权限过大应修改能力边界而不是只增加一句提示审批频繁拒绝某类动作说明阈值或流程需要调整。治理不是上线前盖一个章而是让每次失败都改变系统。结语Agent 的工程难点来自模型的不确定性、工具的真实副作用和任务的长链路。Runtime 用确定性边界和可观测状态承接这些不确定性Control Policy 用反馈、拓扑、审批和恢复机制约束行动Evaluation / Governance 则独立判断系统是否可靠、是否安全、是否值得继续运行。因此设计 Agent 时不应只问“提示词怎么写”还要问它能接触什么状态保存在哪里凭什么判断完成失败和副作用如何发现哪些动作必须由人负责这些问题回答清楚Agent 才从一次性的智能演示变成可以进入真实业务流程的系统。