工程篇难度 3⏱ 9 分钟工具
01AutoGen（微软多Agent框架）
微软开源的多智能体协作框架，通过异步消息驱动多个 Agent 角色分工完成复杂任务。
AutoGen微软多Agent对话式GroupChat
更新于 2026-03-26autogen
让模型能稳定作为 Agent 运行的一层工程化控制系统，负责调度、约束、反馈与恢复。
内容摘要
Agent Harness（Agent 脚手架 / 运行时控制层）不是某一个固定产品名，而是一类工程化系统层。它包在模型和业务任务之间，负责把“会回答问题的模型”变成“能持续执行任务的 Agent”。如果把大模型看成推理引擎，那么 Harness 更像是它的运行时外壳：接收任务、组织上下文、暴露工具、管理状态、限制权限、校验结果，并在出错时决定是重试、回滚、求助人类，还是交给别的子 Agent。
Agent Harness（Agent 脚手架 / 运行时控制层）不是某一个固定产品名，而是一类工程化系统层。它包在模型和业务任务之间，负责把“会回答问题的模型”变成“能持续执行任务的 Agent”。如果把大模型看成推理引擎，那么 Harness 更像是它的运行时外壳：接收任务、组织上下文、暴露工具、管理状态、限制权限、校验结果，并在出错时决定是重试、回滚、求助人类，还是交给别的子 Agent。
它之所以出现，是因为真实 Agent 系统的难点往往不在“模型这一次能不能答对”，而在“它能不能连续几十步都不跑偏”。一旦任务拉长，系统就会遇到上下文膨胀、工具误用、状态丢失、权限越界、错误累积、结果无法验证等问题。单靠提示词或单个框架 API，很难把这些问题一起兜住。
因此，Agent Harness 的核心价值不是替代模型，也不是替代 Agent Framework（Agent 开发框架），而是提供一层运行时控制与工程约束。它把规划、执行、验证、纠偏、持久化、审计这些能力串成闭环，让 Agent 从“能跑 demo”变成“能在生产环境里持续跑任务”的系统。
2026 年这一波关于 Harness 的讨论重新升温，核心原因并不是“又出现了一个新框架”，而是 OpenAI 在两篇官方文章里把它讲得更具体了。
第一篇是 OpenAI 在 2026 年 2 月发布的《Harness engineering: leveraging Codex in an agent-first world》。这篇文章强调，当 agent-first workflow 成为默认开发方式之后，工程师的重点会从“直接写代码”转向“设计环境、约束、反馈和仓库可读性”。这里说的 Harness，不再只是一个抽象概念，而是 agent 执行所依赖的控制面。
第二篇是《Harnessing Codex to work on open source》。这篇文章更贴近系统实现，明确提到 Codex harness 里包含 thread lifecycle、state persistence、config/auth、tool execution、extensions 这些能力。也就是说，Harness 不是“模型旁边的一层模糊胶水”，而是一个真实存在的运行时系统层。
所以这波“Agent Harness”重新变热，本质上不是话题包装，而是大家开始逐渐把 Agent 看成一个长期运行的系统，而不是一次性问答接口。只要任务不是单轮结束，而是要持续执行、调工具、记状态、可恢复、可观测，Harness 就会自然进入讨论核心。
| 结构 | 作用 | 说明 |
|---|---|---|
| 任务入口与上下文装配 | 把用户目标翻译成可执行任务 | 负责指令、状态、记忆、工具说明、环境信息的组装与裁剪 |
| 执行编排与工具调度 | 让 Agent 能分步骤推进任务 | 决定调用哪个工具、是否切分子任务、是否交接给子 Agent |
| 状态、记忆与检查点 | 保持长任务连续性 | 保存中间结果、线程状态、检查点，支持恢复与回放 |
| 约束与反馈回路 | 防止系统持续跑偏 | 包含权限控制、输入输出校验、测试验证、重试、人工审批 |
Harness 的第一件事不是“让模型开始想”，而是先把任务包装成适合运行的上下文。这里通常会做三件事：
这一步决定了 Agent 是“拿着完整说明书上手”，还是“带着一堆噪声边走边猜”。
模型本身只能生成下一步文本，但 Agent 系统需要决定“下一步动作”。Harness 会把文本决策翻译成具体执行：调用工具、写文件、读取网页、发起检索、交给其他 Agent、或者结束任务。
如果任务较长，Harness 往往还会维护一个显式执行循环，例如“计划 → 执行 → 观察 → 再计划”。这也是它和普通聊天调用最本质的区别：它不是一次回答，而是一条持续推进的任务链。
长任务必须能“记得住自己做到哪了”。Harness 通常会把当前线程状态、历史消息、工具结果、文件变更、任务计划、审批结论等信息持久化。这样当进程中断、工具失败、人工接管或者任务需要隔天继续时，系统仍然可以从最近的可恢复点继续。
这部分能力和 LangGraph 一类框架中的 state / checkpoint 很接近，但 Harness 的关注点更宽，不只保存状态，还要决定哪些状态该保留、怎样交接、哪些结果需要暴露给下游环节。
Harness 的核心不是“放权”，而是“可控地放权”。因此它通常包含：
这意味着 Agent 不只是“做事”，还要被持续检查“做得对不对”。
Agent Harness 的工作逻辑可以理解成一个“受控自治循环”：
这套机制之所以有效，是因为它把“推理”和“控制”拆开了：模型负责提出下一步，Harness 负责把这一步落到真实世界里，并判断是否继续放行。只有这样，Agent 才不会因为一次错误的工具调用或者一次错误的上下文选择而一路失控。
图中的关键点有三个：
下面用伪代码展示 Harness 的最小闭环。它不是某个框架的完整实现，但能表达运行时控制层的核心职责。
from dataclasses import dataclass, field
from typing import Any
@dataclass
class AgentState:
"""Agent 运行时状态。"""
goal: str
history: list[str] = field(default_factory=list)
checkpoints: list[dict[str, Any]] = field(default_factory=list)
done: bool = False
def plan_next_action(state: AgentState) -> dict[str, Any]:
"""用模型或规则决定下一步动作。"""
if not state.history:
return {"type": "tool", "name": "search_docs", "args": {"query": state.goal}}
return {"type": "answer", "content": "基于检索结果整理最终回答"}
def run_tool(name: str, args: dict[str, Any]) -> str:
"""真正执行工具。"""
if name == "search_docs":
return f"检索完成：{args['query']} 的 3 条相关资料"
raise ValueError(f"未知工具：{name}")
def validate_step(result: str) -> bool:
"""最小验证器：这里只演示运行时会做校验。"""
return bool(result and result.strip())
def save_checkpoint(state: AgentState) -> None:
"""保存检查点，便于中断恢复。"""
state.checkpoints.append(
{
"history": list(state.history),
"done": state.done,
}
)
def run_harness(goal: str) -> AgentState:
"""最小 Harness 循环。"""
state = AgentState(goal=goal)
while not state.done:
action = plan_next_action(state)
if action["type"] == "tool":
tool_result = run_tool(action["name"], action["args"])
if not validate_step(tool_result):
state.history.append("工具结果校验失败，进入重试/纠偏")
continue
state.history.append(tool_result)
save_checkpoint(state)
elif action["type"] == "answer":
if not validate_step(action["content"]):
state.history.append("输出为空，拒绝结束")
continue
state.history.append(action["content"])
state.done = True
save_checkpoint(state)
return state
这段代码对应四个关键机制：plan_next_action 表示决策层，run_tool 表示执行层，validate_step 表示反馈约束，save_checkpoint 表示持久化恢复。真实系统会把这里的函数替换成 LLM、工具平台、权限系统、状态存储、评测器和人工审批节点。
| 概念 | 与 Agent Harness 的区别 | 更适合关注的重点 |
|---|---|---|
| Agent Framework（Agent 开发框架） | Framework 主要提供组件、接口和编程模型；Harness 更强调运行时控制、约束和交付闭环 | 看它如何定义节点、工具、状态、编排 API |
| Context Engineering（上下文工程） | 上下文工程是 Harness 的一部分，解决“给模型喂什么”；Harness 还要解决执行、验证、恢复、权限等问题 | 看上下文如何筛选、压缩、检索和注入 |
| Guardrails（护栏） | Guardrails 主要负责限制与校验；Harness 还包括调度、状态、记忆、检查点、交接等完整控制面 | 看它如何拦截风险输入输出 |
| Agent Runtime（Agent 运行时） | 两者高度重叠；Runtime 偏执行环境这一层，Harness 常额外强调工程化控制和可运营性 | 看它是否支持恢复、审计、反馈闭环 |
核心区别：
再换一个更贴近最近文章的理解方式：
这两个词经常一起出现，但层级并不一样：前者偏系统层，后者偏方法论层。
| 常见误区 | 正确理解 |
|---|---|
| Agent Harness 就是某一个新框架或某个产品名 | 它更像一类工程角色或系统层，不同团队会用不同框架和工具来实现 |
| 只要用了 Agent Framework，就等于有了 Harness | 框架提供开发积木，不等于已经具备恢复、权限、验证、审计、纠偏等完整运行时控制 |
| Harness 的目的就是限制模型 | 限制只是其中一部分，它更重要的职责是调度、反馈、恢复和交接，让自治变成可控自治 |
| Harness 可以替代评测和人工监督 | 它能承载评测和审批节点，但不能免除评测体系建设，也不能消除高风险场景下的人类责任 |
参考答案：
因为在真实 Agent 系统里，问题往往出在多步执行链路：上下文会膨胀、工具可能误用、任务会中断、错误会累积、结果还需要验证。模型单轮答得好，不代表它能稳定跑完整个任务。Harness 负责把这些运行时问题兜起来。
参考答案：
Framework 更像开发框架，重点是提供节点、工具、状态、工作流等抽象，帮助开发者搭建 Agent。Harness 更像运行时控制层，重点是把上下文装配、工具调度、检查点、权限、护栏、验证、重试、人工审批串成闭环。一个系统可以基于某个 Framework 来实现自己的 Harness。
参考答案：
至少不能省略三类控制点：第一，权限与审批，因为写文件、执行命令、提交补丁都属于高影响动作；第二，状态与检查点，因为代码任务通常较长，失败后需要恢复和复盘；第三，验证与反馈回路，因为必须依赖测试、lint、diff 检查等外部反馈判断补丁是否真的可用，否则 Agent 很容易“看起来修好了，实际没修”。
优先展示同分类且标签更接近的内容，方便继续串联学习。
微软开源的多智能体协作框架，通过异步消息驱动多个 Agent 角色分工完成复杂任务。
开源自主 Agent 平台，支持可视化搭建和部署持续运行的 AI Agent 工作流。
deepset 开源的 AI 编排框架，用模块化管道构建 RAG、语义搜索和 Agent 应用。