《Agent Runtime 工程化》D2：Agent Loop、Harness、Runtime 到底是什么关系？
系列：Agent Runtime 工程化社区文章 编号：D2 摘要：这三个词混在一起讲，最后一定会把架构画糊
Agent Loop、Harness、Runtime 到底是什么关系？
这几年 Agent 讨论里，有几个词特别容易搅在一起：Agent Loop、Harness、Runtime。
很多文章会这么写：
Agent Runtime = 一个 while loop + tools
或者反过来：
Harness 就是 Runtime。
再或者：
有了 MCP，再接一个 agent framework，就差不多是生产级 Agent 了。
我不太赞同。
不是因为这些说法完全错，而是它们都只说中了某一层。工程上最怕这种'局部正确'。局部正确的词一旦进了架构图，后面权限、trace、checkpoint、eval、上下文预算都不知道该挂在哪里。项目越做越大，大家开始用同一个词吵不同的事。
先给我的划分：
Agent Loop 负责让模型一轮轮地想和做。
Harness 负责给这个循环加约束、工具、上下文和评测。
Runtime 负责把一次 Agent 执行变成可恢复、可观测、可治理的系统过程。
这三个词不是同义词。它们像三层不同厚度的系统边界。
为什么现在必须把词讲清楚
以前做 LLM 应用，很多系统就是一次请求、一次回答。最多加 RAG、加函数调用、加缓存。边界相对简单。
Agent 不一样。
它会反复调用模型。会拿工具结果继续决策。会读文件、写文件、执行命令、访问外部系统。长一点的任务可能跑十几步、几十步，中途经历超时、权限确认、上下文压缩、模型降级、工具失败和用户打断。
这时候，如果你把所有东西都叫 'agent'，设计会很快失焦。
Anthropic 在 "Building effective agents" 里把 workflow 和 agent 区分得比较清楚：workflow 是预先编排 LLM 和工具的系统；agent 是模型自己动态决定流程和工具使用的系统。这个划分有帮助，但它还没解决工程实现里的另一层问题：当 agent 真要运行起来，谁来管理状态、权限、预算、恢复和观测？
LangChain 生态现在也开始把层次拆得更细。LangGraph 文档里，Deep Agents 被放在 harness 层，LangChain 是 framework，LangGraph 是 runtime，LangSmith 是 platform。这套分层很有意思，至少说明社区已经意识到：光说 agent framework 不够了。
OpenAI Agents SDK 也有类似信号。文档里会区分 'agent loop 由 SDK 管理' 和 'Responses API 让你自己管理每一轮'。这其实就是在提醒开发者：tool call roundtrip 不是一行 API 调用结束的事，循环控制本身是系统责任。
所以今天讲 Loop、Harness、Runtime，不是术语洁癖。是为了让架构能落地。
Agent Loop：最小控制结构
Agent Loop 是最小骨架。
它解决一个问题：模型不是一次性给最终答案，而是可以在多轮中决定下一步。
一个简化版 loop 长这样：
for (let step = 0; step < maxSteps; step++) {
const response = await model.generate({ messages, tools });
if (response.type === "final") {
response.;
}
results = (response.);
messages.(response, ...results);
}
