Agent Harness：正在形成的工程共识

为什么说它趋向共识？

不同社区用词略有差异，但都在指向同一个事实：agent 的可靠性来自模型外的运行系统。

Anthropic

Harness as agent OS

Engineering 文章连续讨论 effective harnesses、long-running app harness、Managed Agents。harness 管理模型调用、工具、上下文、handoff、sandbox 和 session。

LangChain

If you're not the model, you're the harness

Deep Agents 直接自称 batteries-included agent harness，包含 planning、filesystem、permissions、subagents、skills、memory、context management、code execution。

Cloud / Industry

Runtime + Ops layer

AWS AgentCore harness、MongoDB、Parallel、Lightning 等文章把 harness 描述为生产 agent 的 runtime、状态、验证、权限和观测层。

Raw LLM 不是 agent。模型只有被 harness 包起来，获得状态、工具、反馈、约束和恢复能力后，才成为能做事的系统。这就是当前最稳定的共识。

已经形成的 6 个共识

这些共识基本跨越了 Anthropic、LangChain、云厂商和外部技术社区。

1. 模型不是 agent

模型只是 next-token engine。agent 需要目标、工具、状态、行动循环、反馈和约束。

2. Harness 是执行系统

它把模型智能转成可执行工作：prompt contract、tool interface、agent loop、state、context、permissions、eval。

3. Harness 决定接近上限的程度

同一模型换不同 harness，长任务、coding、design、web automation 的表现会差很多。

4. Context window 不是任务状态

长任务必须有 session log、task artifacts、memory files、structured handoff，而不是只靠 chat history。

5. 安全要靠结构，不靠自律

凭据、sandbox、tool allowlist、approval gate 应由 harness 结构性保证，不是写在 prompt 里。

6. 多 agent 需要共享运行时

多 agent 不只是互相发消息，而是 shared state、shared tools、resource ownership、permissions、failure recovery。

我的定义

为了避免“除了模型之外全叫 harness”导致概念变空，我会给它一个较窄但足够完整的定义。

Agent harness 是围绕模型构建的一套任务执行运行时。它负责把用户意图转化为可恢复、可约束、可验证的行动循环，并管理模型与工具、状态、上下文、权限、环境、评测和人类之间的接口。

Harness = Prompt contract + Tool interface + Agent loop + State / session management + Context lifecycle + Execution environment + Permission boundary + Verification / eval + Observability + Recovery / handoff

团队级 harness 分层

对研发团队来说，harness 不只是一个库，而是把 AI 接入研发流程的一组层次。

Model

Claude / GPT / Gemini / local model：能力底座，但不是完整 agent。

Tool Harness

function calling、MCP、shell、browser、file edit、git。

Task Harness

plan-act-observe loop、todo、task ledger、handoff、retries。

Context Harness

retrieval、memory、compaction、session log、prompt cache。

Verification Harness

tests、linters、evals、reviewer agent、human approval。

Security Harness

sandbox、scoped credentials、policy、allowlist、approval gates。

Workflow Harness

issue、PR、CI/CD、deploy、rollback、ownership、SLA。

Meta-Harness

multiple harnesses、multiple agents、resource registry、session orchestration。

还没有完全统一的边界

概念趋向共识，但仍处在定义扩张期。要避免把词用烂。

Harness vs Platform

我更倾向区分：harness 管一个 agent/task 的执行结构；platform 管跨团队、跨 harness 的部署、治理、成本和观测。

Generic vs Task-specific

通用 harness 适合默认任务；任务特定 harness 适合高价值、高重复、可评测领域；meta-harness 负责容纳多种 harness。

Framework ≠ Harness

LangGraph、Claude Agent SDK、OpenAI Agents SDK 是 building blocks；真正 harness 还包括团队如何做状态、权限、review、CI/CD。

概念滥用风险

一个简单 wrapper 也可以叫 harness，但真正有生产价值的 harness 至少要处理状态、工具、恢复和验证。

对研发团队意味着什么？

团队竞争力会从“谁 prompt 写得好”，转向“谁能把研发流程改造成适合 agent 工作的 harness”。

以前的问题	Harness 视角的问题	对应建设
用哪个模型？	模型如何接入任务状态和工具？	TaskSession + tool registry
怎么让它多干点？	长任务如何恢复、分解、验证？	event log + artifacts + evaluator
怎么写 prompt？	prompt contract 如何与权限/工具/流程一致？	system prompts + policies + scopes
怎么做多 agent？	shared state、resource ownership、handoff 怎么设计？	meta-harness + resource registry
怎么避免乱操作？	安全边界是不是结构性的？	sandbox + vault/proxy + approval gates

对 Crewden 的判断

Crewden 的核心不应该是“再加几个 agent 角色”，而应该是构建可靠的 task harness / meta-harness。

不要优先做

堆 planner / researcher / coder / reviewer / deployer 角色
agent 之间自然语言互传 summary
依赖 manager agent 记住全局状态
让机制互相阻塞，用户被迫协调

应该优先做

TaskSession 作为中心对象
event log + artifacts 作为 handoff 事实
repo / browser / CI / deploy 作为可移交 hands
scoped capability 和 recovery state

TaskSession user_goal constraints event_log[] artifacts[] resources[] permissions[] active_brain available_hands[] recovery_state verification_status

最终判断

harness 已经基本成为 agent 工程的核心共识词，但仍在定义扩张期。

Harness 是 AI 时代的软件运行时。它把一个会思考的模型，接入真实世界的工具、状态、权限和反馈循环，让它能够长期、安全、可恢复地完成任务。

简单任务

chat + tool call 就够了，不必过度工程化。

高价值长任务

需要 task session、event log、sandbox、eval、handoff。

组织级 AI-native

需要 workflow harness 和 meta-harness，把研发流程变成 agent-operable。