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 解决的是 capability，production 要解决的是 reliability
Demo 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 Layer
Prompt 仍然重要，但它在 production system 里的角色需要重新理解。
Prompt 不只是“告诉模型做什么”，而更像：
- role definition
- safety boundary
- tool-use heuristics
- output contract
- escalation policy
- fallback hints
所以 prompt 更接近 execution policy surface，而不是一段孤立的文字技巧。
2.2 Context Layer
上下文是 agent 的即时工作内存。
它决定模型此刻“看到了什么”，也决定模型此刻“忽略了什么”。
在 production agent 里，context 设计至少包括：
- static instructions
- task-local state
- recent interaction history
- retrieved memory
- tool outputs
- environment snapshots
- policy and permission constraints
而 context engineering 的难点就在于平衡：
- 给太少，agent 缺信息
- 给太多，agent 被噪音淹没
- 给得无结构，agent 无法判别优先级
- 给得不可信，agent 会被错误状态劫持
所以 context 不是堆料，而是信息编排。
2.3 Memory Layer
Memory 是 agent 在长任务和跨任务场景中的延伸认知系统。
但 memory 真正难的，从来不是“能不能存”，而是“值不值得取回来”。
一个成熟的 memory layer 至少要回答这些问题：
- 哪些信息应该被记住
- 哪些信息只该短期保留
- 哪些内容应该被压缩而不是原样保留
- 检索时如何避免历史噪音干扰当前判断
- 如何标记 provenance 与置信度
- 何时应该遗忘
如果没有这些 discipline，memory 只会从帮助 agent 变成污染 agent。
2.4 Tool Layer
Tools 是 agent 的行动能力。
但 tool integration 不能只看“能不能调通”，还要看：
- 输入输出是否稳定
- side effects 是否可预测
- 默认行为是否安全
- 错误是否可解释
- 权限边界是否明确
- tool description 是否会污染 agent 判断
换句话说，好的 tool surface 应该像好的 API：
- contract 清晰
- 错误可控
- 默认保守
- audit 友好
2.5 Orchestration Layer
Orchestration 是整个 harness 的 control plane。
它决定：
- 先做什么，后做什么
- 什么时候查 memory
- 什么时候调 tool
- 什么时候切 sub-agent
- 什么时候 asking permission
- 什么时候中断或回退
- 什么时候写入 durable state
这一层如果设计不好，再强的 model 也会表现得像一个不稳定的自动脚本。
2.6 Observability Layer
Observability 是 production capability 的基础。
对于 agent system，至少需要这些观测对象：
- prompt/context snapshot
- memory recall record
- tool call trace
- intermediate outputs
- retries / failures / timeouts
- final action result
- side effect logs
如果没有这些，你甚至无法可靠回答：
- 这次为什么成功？
- 那次为什么失败？
- 是模型错了，还是工具错了？
- 是 context 污染了，还是 memory 检索错了？
2.7 Governance Layer
Governance 是很多团队最晚补、但实际上最早该想清楚的一层。
它包括：
- approval gates
- role-based permissions
- sandboxing
- audit trail
- rollback path
- escalation rules
- compliance constraints
没有 governance，agent 也许能做很多事； 但一旦进入真实业务环境，它就会因为不可控而无法被信任。
三、为什么说它是“新的 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）真正的复杂性都来自外围系统
- 数据、部署、监控之于 ML
- context、tools、memory、governance 之于 agent
（3）成功标准都从 capability 变成 reliability
- 不是“能训练出来”
- 而是“能否持续、稳定、可控地工作”
（4）都需要闭环
- MLOps 需要 data → train → deploy → observe → improve
- Agent Harness 需要 task → context → act → observe → learn → refine
四、一个更完整的方法论框架
如果要把 Agent Harness 变成一个可操作的方法论，我更倾向于用三层结构来理解。
Layer 1：Intelligence
这是 agent 的认知引擎层，主要包括：
- foundation model quality
- reasoning capability
- multimodal ability
- latency / cost envelope
这一层决定：
- 它能理解多复杂的问题
- 它能进行多深的推理
- 它能处理什么模态输入
但它只决定上限，不保证稳定落地。
Layer 2：Harness
这是把智能转化为执行能力的中间层，主要包括：
- prompt system
- context assembly
- memory recall / compaction
- tool protocol and skill surface
- orchestration and task routing
- progress tracking
- logging / replay / eval
这一层决定：
- 它会不会乱用能力
- 它能不能把能力稳定发挥出来
- 它能不能处理复杂任务中的状态变化
Layer 3：Governance
这是把执行能力纳入现实约束的控制层，主要包括：
- permissions
- approval workflows
- sandboxing
- audit
- rollback
- policy enforcement
- compliance 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 的根因，其实在 harness：
- retrieval 脏
- 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 persistence？
Observability
- 是否保留关键 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 system：recall、compaction、provenance 如何设计才不会污染决策？
- AgentOps metrics：task success、latency、retry、fallback、approval rate、memory hit quality 应如何组合？
- Governance-first agent architecture：为什么高风险场景更需要 policy-before-autonomy？
- AIOps 里的 agent harness：如何和 SLO、incident workflow、human escalation、postmortem 体系打通？
