Agent Harness正在成为新的 MLOps引子过去一年很多人谈 agent讨论重点还主要集中在两个问题上模型够不够强prompt 写得好不好这两个问题当然重要但越来越不够了。如果只是做一个 demo它们也许已经够用选一个不错的 model写一个像样的 system prompt接几个 tools让它跑起来看上去一个“agent”就诞生了。但只要系统真正进入持续使用、真实任务、长上下文、多步骤执行的阶段事情马上就会变得完全不同。你会发现真正决定 agent 是否可用的往往不是 model intelligence 本身而是围绕 intelligence 建起来的那一整套执行系统它怎么管理上下文它怎么处理记忆它怎么调用工具它怎么做状态持久化它怎么处理失败和回退它怎么被观测、调试、审计它怎么被 policy 和 approval 约束这整套东西可以统一称为Agent Harness而如果把这个趋势放到更长的技术演化路径里看会发现它和当年 MLOps 的出现非常相似。MLOps 让行业意识到真正的 ML 系统不是模型训练脚本本身而是围绕数据、训练、部署、监控、反馈建立起来的完整工程链路。今天Agent Harness 正在让我们意识到另一件事真正可用的 agent不是 prompt model而是围绕上下文、工具、记忆、执行控制和治理建立起来的完整运行体系。所以这篇文章想讨论的核心命题是Agent Harness正在成为新的 MLOps。一、为什么“会跑”不等于“可用”很多 agent 的第一阶段成功都有一种共同幻觉能调模型能调工具能做几步自动执行偶尔还能完成惊艳的任务于是团队会以为问题已经基本解决剩下只是调优。但事实通常相反。真正的难题往往在 demo 成功之后才开始出现。1.1 Demo 解决的是 capabilityproduction 要解决的是 reliabilityDemo agent 的目标通常是证明这个任务模型能理解这个工具接口可以调用这个 workflow 理论上走得通而 production agent 需要解决的是多轮对话后会不会失去状态工具失败后会不会卡死或误操作长上下文下记忆会不会污染决策输出结构会不会漂移相似任务能不能稳定复现外部依赖异常时有没有 fallback整个执行过程是否可观察、可中断、可回滚这两者的关注点完全不同。前者关注“能不能”后者关注“稳不稳、可不可控、能不能长期运行”。1.2 Agent 一旦接触真实世界就不再只是 NLP 问题如果 agent 只做纯文本问答那么问题多数还停留在语言理解和知识生成层。但一旦 agent 开始接触真实执行面例如读写文件打开浏览器调 shell / API操作代码仓库管理任务状态调用多个工具链处理跨轮对话历史它就已经不是一个单纯的语言系统而是一个计算机使用系统。此时失败模式也从“答错了”扩展成调错工具调对工具但顺序错了工具返回异常没处理读取了过期状态上下文里混入错误记忆行为越权外部副作用不可逆这意味着 agent engineering 的核心正在从 prompt craftsmanship 转向systems engineering。二、Agent Harness 到底是什么如果要给 Agent Harness 一个工程化定义可以这样表述Agent Harness 是围绕 LLM 构建的执行控制层它负责把模型能力转化为稳定、可控、可观测、可治理的任务执行能力。它不是单一组件而是一组协同工作的 runtime layer。2.1 Prompt LayerPrompt 仍然重要但它在 production system 里的角色需要重新理解。Prompt 不只是“告诉模型做什么”而更像role definitionsafety boundarytool-use heuristicsoutput contractescalation policyfallback hints所以 prompt 更接近execution policy surface而不是一段孤立的文字技巧。2.2 Context Layer上下文是 agent 的即时工作内存。它决定模型此刻“看到了什么”也决定模型此刻“忽略了什么”。在 production agent 里context 设计至少包括static instructionstask-local staterecent interaction historyretrieved memorytool outputsenvironment snapshotspolicy and permission constraints而 context engineering 的难点就在于平衡给太少agent 缺信息给太多agent 被噪音淹没给得无结构agent 无法判别优先级给得不可信agent 会被错误状态劫持所以 context 不是堆料而是信息编排。2.3 Memory LayerMemory 是 agent 在长任务和跨任务场景中的延伸认知系统。但 memory 真正难的从来不是“能不能存”而是“值不值得取回来”。一个成熟的 memory layer 至少要回答这些问题哪些信息应该被记住哪些信息只该短期保留哪些内容应该被压缩而不是原样保留检索时如何避免历史噪音干扰当前判断如何标记 provenance 与置信度何时应该遗忘如果没有这些 disciplinememory 只会从帮助 agent 变成污染 agent。2.4 Tool LayerTools 是 agent 的行动能力。但 tool integration 不能只看“能不能调通”还要看输入输出是否稳定side effects 是否可预测默认行为是否安全错误是否可解释权限边界是否明确tool description 是否会污染 agent 判断换句话说好的 tool surface 应该像好的 APIcontract 清晰错误可控默认保守audit 友好2.5 Orchestration LayerOrchestration 是整个 harness 的 control plane。它决定先做什么后做什么什么时候查 memory什么时候调 tool什么时候切 sub-agent什么时候 asking permission什么时候中断或回退什么时候写入 durable state这一层如果设计不好再强的 model 也会表现得像一个不稳定的自动脚本。2.6 Observability LayerObservability 是 production capability 的基础。对于 agent system至少需要这些观测对象prompt/context snapshotmemory recall recordtool call traceintermediate outputsretries / failures / timeoutsfinal action resultside effect logs如果没有这些你甚至无法可靠回答这次为什么成功那次为什么失败是模型错了还是工具错了是 context 污染了还是 memory 检索错了2.7 Governance LayerGovernance 是很多团队最晚补、但实际上最早该想清楚的一层。它包括approval gatesrole-based permissionssandboxingaudit trailrollback pathescalation rulescompliance constraints没有 governanceagent 也许能做很多事但一旦进入真实业务环境它就会因为不可控而无法被信任。三、为什么说它是“新的 MLOps”这个类比不是修辞而是结构上的相似。3.1 MLOps 解决的问题模型不是系统在早期 ML 工程里很多人会把模型训练脚本当成系统主体。但后来行业慢慢意识到真正困难的不是把模型训练出来而是数据从哪里来特征怎么构造训练如何复现部署如何自动化线上性能如何监控模型漂移如何识别反馈如何回流于是 MLOps 出现了。它让“模型工程”变成了“模型生命周期工程”。3.2 Agent Harness 解决的问题LLM 不是 agent system今天 agent 也在经历类似认知转变。团队开始意识到真正困难的不是“让 LLM 调一下工具”而是怎么组织上下文怎么设计 memory lifecycle怎么管控 tool side effects怎么处理长任务状态怎么让执行过程可 replay怎么给人类留出 review / interrupt 点怎么把整个系统纳入 policy 和 audit因此 Agent Harness 的出现本质上就是把“agent demo”升级成“agent lifecycle engineering”。3.3 两者的共同点MLOps 与 Agent Harness 至少有四个共同点1核心对象都只是冰山一角MLOps 中model 只是系统的一部分Agent system 中LLM 也只是系统的一部分2真正的复杂性都来自外围系统数据、部署、监控之于 MLcontext、tools、memory、governance 之于 agent3成功标准都从 capability 变成 reliability不是“能训练出来”而是“能否持续、稳定、可控地工作”4都需要闭环MLOps 需要 data → train → deploy → observe → improveAgent Harness 需要 task → context → act → observe → learn → refine四、一个更完整的方法论框架如果要把 Agent Harness 变成一个可操作的方法论我更倾向于用三层结构来理解。Layer 1Intelligence这是 agent 的认知引擎层主要包括foundation model qualityreasoning capabilitymultimodal abilitylatency / cost envelope这一层决定它能理解多复杂的问题它能进行多深的推理它能处理什么模态输入但它只决定上限不保证稳定落地。Layer 2Harness这是把智能转化为执行能力的中间层主要包括prompt systemcontext assemblymemory recall / compactiontool protocol and skill surfaceorchestration and task routingprogress trackinglogging / replay / eval这一层决定它会不会乱用能力它能不能把能力稳定发挥出来它能不能处理复杂任务中的状态变化Layer 3Governance这是把执行能力纳入现实约束的控制层主要包括permissionsapproval workflowssandboxingauditrollbackpolicy enforcementcompliance boundary这一层决定它能不能被组织信任它能不能进入真实工作流它出了问题后是否可解释、可纠偏4.1 三层之间的关系Intelligence提供可能性Harness提供稳定性Governance提供可部署性因此真正成熟的 agent system 不是Good model good product而是Good model × Good harness × Good governance deployable agent system五、对企业团队最现实的启发5.1 不要把大多数 agent 问题误诊成 model problem很多团队一遇到效果不好第一反应就是换更强模型加更长上下文再写一个更复杂的 prompt但很多 failure 的根因其实在 harnessretrieval 脏memory 污染tool contract 不稳定orchestration 混乱中间状态没被约束缺少 review / checkpoint如果误把 harness 问题当成 model 问题只会让系统越来越贵却不一定更稳。5.2 高风险场景里governance 比 autonomy 更重要在企业环境、AIOps、合规行业、内部自动化等场景里真正重要的不是 agent 有多“自主”而是是否 bounded是否 explainable是否 interruptible是否 replayable是否 auditable也就是说不是越 autonomous 越好而是越 governable 越能落地。5.3 Workflow ownership 才是 agent 产品的长期护城河模型会变tool protocol 会商品化基础能力会逐渐趋同。真正不容易被替代的是对真实 workflow 的理解对状态与异常的处理能力对 memory / routing / review 的编排能力与组织治理结构的深度结合所以 agent 产品的壁垒更像 workflow system execution control而不是单点 model access。六、一个 practical checklist如何判断一个 agent 系统是否接近 production可以用下面这些问题做快速诊断Context上下文是结构化编排的吗是否区分 instruction、state、memory、tool output是否有信息优先级控制Memory是否有明确的写入标准是否支持 compaction / summarization是否能标记来源与置信度是否有遗忘策略Tools工具 contract 是否稳定side effect 是否显式默认行为是否安全错误是否能被 agent 和人类同时理解Orchestration是否有清晰的 task routing是否能在失败时 fallback是否支持 interruption / resume是否支持 long-running state persistenceObservability是否保留关键 trace是否支持 replay是否能回答“为什么失败/成功”是否能定位是 model、memory、tool 还是 orchestration 的问题Governance是否有 approval gates是否有最小权限原则是否支持 sandbox是否有 audit trail 和 rollback path如果这些问题大多数回答还是“不确定”那系统大概率还停留在 demo 阶段。七、最后的结论未来 agent 体系的成熟不会只靠模型继续变强。模型会继续进步这当然重要但真正决定 agent 能不能进入生产环境、成为稳定劳动力、承担真实 workflow 的是它外围的 harness。所以对 agent 的更准确理解应该是Agent Intelligence Harness Governance其中Intelligence 决定它能做到多聪明Harness 决定它能不能稳定地把聪明转化为结果Governance 决定它能不能被现实世界信任和采用如果必须压缩成一句话那我更愿意这样说真正可用的 agent难点不在智能本身而在智能外围的一整套工程系统。而这整套工程系统正在成为 AI 时代新的基础设施 discipline。也许几年后回头看我们会像今天谈 MLOps 一样自然地谈 Agent Harness / AgentOps。因为那时大家已经默认知道LLM 不是系统agent 也不是 prompt。真正决定长期价值的是能不能把智能组织成一个稳定运行的系统。可继续深挖的话题Agent Harness 与 MCP 标准化哪些层会被平台化哪些层仍会是差异化壁垒长任务 memory systemrecall、compaction、provenance 如何设计才不会污染决策AgentOps metricstask success、latency、retry、fallback、approval rate、memory hit quality 应如何组合Governance-first agent architecture为什么高风险场景更需要 policy-before-autonomyAIOps 里的 agent harness如何和 SLO、incident workflow、human escalation、postmortem 体系打通
Agent Harness，正在成为新的 MLOps
发布时间：2026/5/19 10:49:10
Agent Harness正在成为新的 MLOps引子过去一年很多人谈 agent讨论重点还主要集中在两个问题上模型够不够强prompt 写得好不好这两个问题当然重要但越来越不够了。如果只是做一个 demo它们也许已经够用选一个不错的 model写一个像样的 system prompt接几个 tools让它跑起来看上去一个“agent”就诞生了。但只要系统真正进入持续使用、真实任务、长上下文、多步骤执行的阶段事情马上就会变得完全不同。你会发现真正决定 agent 是否可用的往往不是 model intelligence 本身而是围绕 intelligence 建起来的那一整套执行系统它怎么管理上下文它怎么处理记忆它怎么调用工具它怎么做状态持久化它怎么处理失败和回退它怎么被观测、调试、审计它怎么被 policy 和 approval 约束这整套东西可以统一称为Agent Harness而如果把这个趋势放到更长的技术演化路径里看会发现它和当年 MLOps 的出现非常相似。MLOps 让行业意识到真正的 ML 系统不是模型训练脚本本身而是围绕数据、训练、部署、监控、反馈建立起来的完整工程链路。今天Agent Harness 正在让我们意识到另一件事真正可用的 agent不是 prompt model而是围绕上下文、工具、记忆、执行控制和治理建立起来的完整运行体系。所以这篇文章想讨论的核心命题是Agent Harness正在成为新的 MLOps。一、为什么“会跑”不等于“可用”很多 agent 的第一阶段成功都有一种共同幻觉能调模型能调工具能做几步自动执行偶尔还能完成惊艳的任务于是团队会以为问题已经基本解决剩下只是调优。但事实通常相反。真正的难题往往在 demo 成功之后才开始出现。1.1 Demo 解决的是 capabilityproduction 要解决的是 reliabilityDemo agent 的目标通常是证明这个任务模型能理解这个工具接口可以调用这个 workflow 理论上走得通而 production agent 需要解决的是多轮对话后会不会失去状态工具失败后会不会卡死或误操作长上下文下记忆会不会污染决策输出结构会不会漂移相似任务能不能稳定复现外部依赖异常时有没有 fallback整个执行过程是否可观察、可中断、可回滚这两者的关注点完全不同。前者关注“能不能”后者关注“稳不稳、可不可控、能不能长期运行”。1.2 Agent 一旦接触真实世界就不再只是 NLP 问题如果 agent 只做纯文本问答那么问题多数还停留在语言理解和知识生成层。但一旦 agent 开始接触真实执行面例如读写文件打开浏览器调 shell / API操作代码仓库管理任务状态调用多个工具链处理跨轮对话历史它就已经不是一个单纯的语言系统而是一个计算机使用系统。此时失败模式也从“答错了”扩展成调错工具调对工具但顺序错了工具返回异常没处理读取了过期状态上下文里混入错误记忆行为越权外部副作用不可逆这意味着 agent engineering 的核心正在从 prompt craftsmanship 转向systems engineering。二、Agent Harness 到底是什么如果要给 Agent Harness 一个工程化定义可以这样表述Agent Harness 是围绕 LLM 构建的执行控制层它负责把模型能力转化为稳定、可控、可观测、可治理的任务执行能力。它不是单一组件而是一组协同工作的 runtime layer。2.1 Prompt LayerPrompt 仍然重要但它在 production system 里的角色需要重新理解。Prompt 不只是“告诉模型做什么”而更像role definitionsafety boundarytool-use heuristicsoutput contractescalation policyfallback hints所以 prompt 更接近execution policy surface而不是一段孤立的文字技巧。2.2 Context Layer上下文是 agent 的即时工作内存。它决定模型此刻“看到了什么”也决定模型此刻“忽略了什么”。在 production agent 里context 设计至少包括static instructionstask-local staterecent interaction historyretrieved memorytool outputsenvironment snapshotspolicy and permission constraints而 context engineering 的难点就在于平衡给太少agent 缺信息给太多agent 被噪音淹没给得无结构agent 无法判别优先级给得不可信agent 会被错误状态劫持所以 context 不是堆料而是信息编排。2.3 Memory LayerMemory 是 agent 在长任务和跨任务场景中的延伸认知系统。但 memory 真正难的从来不是“能不能存”而是“值不值得取回来”。一个成熟的 memory layer 至少要回答这些问题哪些信息应该被记住哪些信息只该短期保留哪些内容应该被压缩而不是原样保留检索时如何避免历史噪音干扰当前判断如何标记 provenance 与置信度何时应该遗忘如果没有这些 disciplinememory 只会从帮助 agent 变成污染 agent。2.4 Tool LayerTools 是 agent 的行动能力。但 tool integration 不能只看“能不能调通”还要看输入输出是否稳定side effects 是否可预测默认行为是否安全错误是否可解释权限边界是否明确tool description 是否会污染 agent 判断换句话说好的 tool surface 应该像好的 APIcontract 清晰错误可控默认保守audit 友好2.5 Orchestration LayerOrchestration 是整个 harness 的 control plane。它决定先做什么后做什么什么时候查 memory什么时候调 tool什么时候切 sub-agent什么时候 asking permission什么时候中断或回退什么时候写入 durable state这一层如果设计不好再强的 model 也会表现得像一个不稳定的自动脚本。2.6 Observability LayerObservability 是 production capability 的基础。对于 agent system至少需要这些观测对象prompt/context snapshotmemory recall recordtool call traceintermediate outputsretries / failures / timeoutsfinal action resultside effect logs如果没有这些你甚至无法可靠回答这次为什么成功那次为什么失败是模型错了还是工具错了是 context 污染了还是 memory 检索错了2.7 Governance LayerGovernance 是很多团队最晚补、但实际上最早该想清楚的一层。它包括approval gatesrole-based permissionssandboxingaudit trailrollback pathescalation rulescompliance constraints没有 governanceagent 也许能做很多事但一旦进入真实业务环境它就会因为不可控而无法被信任。三、为什么说它是“新的 MLOps”这个类比不是修辞而是结构上的相似。3.1 MLOps 解决的问题模型不是系统在早期 ML 工程里很多人会把模型训练脚本当成系统主体。但后来行业慢慢意识到真正困难的不是把模型训练出来而是数据从哪里来特征怎么构造训练如何复现部署如何自动化线上性能如何监控模型漂移如何识别反馈如何回流于是 MLOps 出现了。它让“模型工程”变成了“模型生命周期工程”。3.2 Agent Harness 解决的问题LLM 不是 agent system今天 agent 也在经历类似认知转变。团队开始意识到真正困难的不是“让 LLM 调一下工具”而是怎么组织上下文怎么设计 memory lifecycle怎么管控 tool side effects怎么处理长任务状态怎么让执行过程可 replay怎么给人类留出 review / interrupt 点怎么把整个系统纳入 policy 和 audit因此 Agent Harness 的出现本质上就是把“agent demo”升级成“agent lifecycle engineering”。3.3 两者的共同点MLOps 与 Agent Harness 至少有四个共同点1核心对象都只是冰山一角MLOps 中model 只是系统的一部分Agent system 中LLM 也只是系统的一部分2真正的复杂性都来自外围系统数据、部署、监控之于 MLcontext、tools、memory、governance 之于 agent3成功标准都从 capability 变成 reliability不是“能训练出来”而是“能否持续、稳定、可控地工作”4都需要闭环MLOps 需要 data → train → deploy → observe → improveAgent Harness 需要 task → context → act → observe → learn → refine四、一个更完整的方法论框架如果要把 Agent Harness 变成一个可操作的方法论我更倾向于用三层结构来理解。Layer 1Intelligence这是 agent 的认知引擎层主要包括foundation model qualityreasoning capabilitymultimodal abilitylatency / cost envelope这一层决定它能理解多复杂的问题它能进行多深的推理它能处理什么模态输入但它只决定上限不保证稳定落地。Layer 2Harness这是把智能转化为执行能力的中间层主要包括prompt systemcontext assemblymemory recall / compactiontool protocol and skill surfaceorchestration and task routingprogress trackinglogging / replay / eval这一层决定它会不会乱用能力它能不能把能力稳定发挥出来它能不能处理复杂任务中的状态变化Layer 3Governance这是把执行能力纳入现实约束的控制层主要包括permissionsapproval workflowssandboxingauditrollbackpolicy enforcementcompliance boundary这一层决定它能不能被组织信任它能不能进入真实工作流它出了问题后是否可解释、可纠偏4.1 三层之间的关系Intelligence提供可能性Harness提供稳定性Governance提供可部署性因此真正成熟的 agent system 不是Good model good product而是Good model × Good harness × Good governance deployable agent system五、对企业团队最现实的启发5.1 不要把大多数 agent 问题误诊成 model problem很多团队一遇到效果不好第一反应就是换更强模型加更长上下文再写一个更复杂的 prompt但很多 failure 的根因其实在 harnessretrieval 脏memory 污染tool contract 不稳定orchestration 混乱中间状态没被约束缺少 review / checkpoint如果误把 harness 问题当成 model 问题只会让系统越来越贵却不一定更稳。5.2 高风险场景里governance 比 autonomy 更重要在企业环境、AIOps、合规行业、内部自动化等场景里真正重要的不是 agent 有多“自主”而是是否 bounded是否 explainable是否 interruptible是否 replayable是否 auditable也就是说不是越 autonomous 越好而是越 governable 越能落地。5.3 Workflow ownership 才是 agent 产品的长期护城河模型会变tool protocol 会商品化基础能力会逐渐趋同。真正不容易被替代的是对真实 workflow 的理解对状态与异常的处理能力对 memory / routing / review 的编排能力与组织治理结构的深度结合所以 agent 产品的壁垒更像 workflow system execution control而不是单点 model access。六、一个 practical checklist如何判断一个 agent 系统是否接近 production可以用下面这些问题做快速诊断Context上下文是结构化编排的吗是否区分 instruction、state、memory、tool output是否有信息优先级控制Memory是否有明确的写入标准是否支持 compaction / summarization是否能标记来源与置信度是否有遗忘策略Tools工具 contract 是否稳定side effect 是否显式默认行为是否安全错误是否能被 agent 和人类同时理解Orchestration是否有清晰的 task routing是否能在失败时 fallback是否支持 interruption / resume是否支持 long-running state persistenceObservability是否保留关键 trace是否支持 replay是否能回答“为什么失败/成功”是否能定位是 model、memory、tool 还是 orchestration 的问题Governance是否有 approval gates是否有最小权限原则是否支持 sandbox是否有 audit trail 和 rollback path如果这些问题大多数回答还是“不确定”那系统大概率还停留在 demo 阶段。七、最后的结论未来 agent 体系的成熟不会只靠模型继续变强。模型会继续进步这当然重要但真正决定 agent 能不能进入生产环境、成为稳定劳动力、承担真实 workflow 的是它外围的 harness。所以对 agent 的更准确理解应该是Agent Intelligence Harness Governance其中Intelligence 决定它能做到多聪明Harness 决定它能不能稳定地把聪明转化为结果Governance 决定它能不能被现实世界信任和采用如果必须压缩成一句话那我更愿意这样说真正可用的 agent难点不在智能本身而在智能外围的一整套工程系统。而这整套工程系统正在成为 AI 时代新的基础设施 discipline。也许几年后回头看我们会像今天谈 MLOps 一样自然地谈 Agent Harness / AgentOps。因为那时大家已经默认知道LLM 不是系统agent 也不是 prompt。真正决定长期价值的是能不能把智能组织成一个稳定运行的系统。可继续深挖的话题Agent Harness 与 MCP 标准化哪些层会被平台化哪些层仍会是差异化壁垒长任务 memory systemrecall、compaction、provenance 如何设计才不会污染决策AgentOps metricstask success、latency、retry、fallback、approval rate、memory hit quality 应如何组合Governance-first agent architecture为什么高风险场景更需要 policy-before-autonomyAIOps 里的 agent harness如何和 SLO、incident workflow、human escalation、postmortem 体系打通
