上一篇我们讨论了一个大的判断Agent 的智能主要来自模型Agent 的可靠运行主要来自 Harness。但这句话仍然比较抽象。如果真正站在架构设计的角度我们还需要继续往下问一个 Agent Harness到底应该负责什么为什么 Claude Code、Codex、DeepSeek Harness 这些系统会逐渐长出 Context、Tool、Session、Permission、Sandbox、Compaction、SubAgent、Hooks 这么多东西概念看起来越来越多很容易让人再次陷入框架和名词里。这一篇我们暂时不讨论具体框架先从第一性原理出发——假设今天没有 Claude Code没有 Codex没有 DeepSeek Harness我们要从零设计一个真正能够持续完成任务的 Agent它必然会遇到哪些问题我认为最终可以归结为六个基本问题图 1 一个真正要工作的 Agent逃不开这六个问题很多今天看起来复杂的 Agent Runtime本质上都在解决这六件事。理解它们比记住任何一个具体框架都重要。一、从零设计一个 Agent假设我们要设计一个 AI 编程助手。用户说帮我分析这个项目把登录模块的 Bug 修掉然后运行测试确认没有问题。如果只有一个大模型 API我们能做的最简单方式是用户需求发给 LLMLLM 输出一段修改建议。模型可能告诉你请打开auth.py修改第 37 行然后运行 pytest。问题马上出现了模型只是告诉你应该做什么真正的任务还没有发生。如果希望 AI 自己完成任务它至少需要能够读取项目文件、搜索代码、修改文件、执行测试、读取报错、继续修改、再次执行测试、判断任务是否完成。于是架构从User → LLM → Answer变成了User → Agent → LLM → Tool → Environment → 结果返回 LLM → 继续决策到这里Agent 才真正开始出现。而接下来六个问题会一个接一个地冒出来。二、持续思考Agent Loop第一个问题Agent 怎么持续思考这就是Agent Loop。很多人第一次理解 Agent 时会把它想得很神秘。其实把外面的能力全部拿掉一个 Agent 最核心的代码可能只有几十行messages [用户任务] while True: response LLM(messages, tools) if response 是最终答案: return response if response 要调用工具: result execute_tool(response.tool_call) messages.append(tool_call) messages.append(tool_result)换成图就是这样图 2 Agent Loop一个持续运转的决策循环OpenAI 对 Codex 的公开解释中把 Agent Loop 定义为连接用户、模型和工具、驱动软件任务执行的核心逻辑Claude Agent SDK 官方文档描述的同样是这个循环。所以第一个结论非常重要Agent 最核心的机制并不复杂它首先是一个循环。复杂的是围绕这个循环逐渐出现的各种工程问题。比如我们的 Coding Agent 第一步执行read_file(auth.py)接着搜索 login、修改文件、运行测试、测试失败、继续修改……很快一个最简单的问题就出现了模型现在到底知道些什么三、知道什么Context 是一种认知资源分配第二个问题Agent 每一次思考时应该知道什么这就是Context——理解现代 Agent 最核心的概念之一。很多时候我们只问模型聪不聪明但对 Agent 来说还有一个同样重要的问题模型在做这个判断时看到了什么同一个模型如果只告诉它修复登录 Bug和告诉它用户任务 项目目录结构 相关源码 之前执行过的命令 测试错误 工具列表 安全约束表现可能完全不同。因此可以写下一个重要公式Agent 的下一步决策 ≈ Model × Current Context模型能力是一个变量Context 也是一个变量。Context 绝不等于聊天记录早期 Chat 应用的 Context 很简单System Prompt 对话历史。到了 Agent 时代Context 会迅速扩张——每次调用模型可能都需要看到下面这些图 3 Model Context每次调用模型到底看到什么这就是 Context Engineering 开始变得重要的原因。真正的问题已经从Prompt 应该怎么写升级成什么信息应该进入模型什么时候进入优先级是什么保留多久太长以后删什么什么信息必须始终存在Claude Agent SDK 已经把 Context Window、Automatic Compaction 和 Session Continuity 作为 Agent Loop 的正式组成部分来处理。真正的困难是有限认知资源分配如果 Context 无限大事情会简单很多——整个项目、全部历史、所有工具结果都塞进去就完了。现实中做不到于是 Harness 必须成为一个Context 管理器。这个角度特别重要人的大脑也不会同时处理所有信息。假设你正在修一个 Bug桌面上的世界有几百万行代码、几十份文档、几千条 Git 历史、几万个 Issue但真正进入你当前工作记忆的也许只有当前 Bug 描述、相关的几个文件、最近一次报错、你的修改假设。Agent 也一样。图 4 Context Engineering 本质上是一种认知资源分配Compaction、Memory、RAG、Skill Loading、SubAgent、Summarization……你会发现很多今天看起来不同的 Agent 技术其实都和同一个问题有关如何管理模型有限的注意力。这可能是未来 Agent Harness 最重要的职责之一。四、改变世界从 Function Calling 到 Capability Runtime第三个问题Agent 怎么真正改变外部世界答案是Tool。模型本身只能产生 Token。它无法真正打开文件、修改数据库、发送邮件、执行 Shell、点击网页。因此需要一个从语言空间到真实世界的桥梁这个桥梁就是 Tool。从模型角度一个 Tool 非常简单名字 说明 输入参数。模型产生read_file({path: src/auth.ts})Harness 接收调用执行真实函数把结果交还。所以有一条非常重要的边界LLM 负责决定调用什么Harness 负责真正执行。Tool 为什么不能只是函数调用做 Demo 时一个工具字典就够了。可一旦进入真正的 Agent Runtime马上会出现一连串问题这个 Tool 当前能不能用参数合法吗允许访问哪个目录执行多久算超时失败是否重试能否并行能否取消结果太大怎么办这个 Agent 有没有权限这个 Tool 会不会修改状态于是 Tool Runtime 会逐渐长成一条执行管线图 5 Tool 的执行管线远不止一次函数调用Claude Agent SDK 就已经区分了只读工具与修改状态的工具多个只读 Tool 可以并发执行而可能修改状态的 Edit、Write、Bash 等操作采用更谨慎的执行策略。这说明 Tool 已经从 Function Calling发展为Capability Runtime。Tool、Skill、MCP 为什么经常被混在一起因为它们都在增强 Agent但解决的问题不同Tool 告诉 Agent你可以做什么Skill 告诉 Agent这类事情应该怎么做MCP 解决外部能力如何用统一协议接进来。图 6 Tool 是能力Skill 是经验MCP 是接入协议五、记住历史Session 与 Event Log第四个问题Agent 怎么记住发生过什么这就是Session。回到那个 Coding Agent用户要求修 Bug → 读取 auth.ts → 搜索 login → 修改 login.ts → 执行 npm test → 测试失败 → 继续修改。如果进程突然退出怎么办电脑重启怎么办用户明天想继续任务怎么办用户想查看刚才 Agent 到底改了什么怎么办想从第 3 步 Fork 出一条新的执行分支怎么办这些问题都意味着同一件事Agent 需要拥有自己的历史。最简单的 Session 是 messages[]但很快不够用很多简单 Agent 会把 messages 数组保存下来这已经能解决多轮对话和恢复上下文。但一个真实 Agent 的生命周期里发生的事情远多于 user / assistant / tool 三种消息任务开始、模型流式输出、工具执行、用户中断、权限批准、上下文压缩、SubAgent 创建、任务恢复、错误重试、任务结束……于是更成熟的系统开始把 Session 理解为Agent 的运行历史而不仅仅是对话消息。DeepSeek Harness 在这里走得比较激进它把 Session 设计成 append-only 的SessionEvent日志明确作为运行状态的事实来源模型看到的历史再从日志中投影出来。图 7 Event Sourcing 思想一份日志多种投影这是经典 Event Sourcing 思想在 Agent 上的应用。优点很明显可回放、可恢复、可 Fork、可审计、可以重新构造模型历史、UI 可以重建执行过程。但代价也同样存在系统复杂度明显增加、事件设计难度提高、投影逻辑增加、调试需要理解事件语义。这是一种架构选择不是所有 Agent 都需要这样做。而 Session 会越来越重要是因为 Agent 正在从一次请求向一个长期存在的执行主体发展早期是 Prompt → Answer后来是 Task → 几分钟执行 → Result未来越来越可能是执行 → 等待外部条件 → 恢复 → 调用其他 Agent → 等待人工 → 继续执行 → 最终完成。一旦进入这种模式Session 就会成为 Agent Runtime 的核心实体之一。六、在哪里做、能不能做Sandbox 与 PermissionSandbox定义 Agent 的物理世界第五个问题Agent 到底在哪里执行操作这是Execution Environment / Sandbox很多人研究 Agent 时容易忽略的一层。模型说执行 npm test真正的问题是在哪个目录执行用哪个用户能访问哪些文件能不能联网能访问 SSH Key 吗命令可以运行多久能不能删除文件能不能访问宿主机所以Tool Agent 想做什么Sandbox Agent 可以在哪个世界里做我们可以把 Agent 想成一个数字生命模型是大脑Tool 是手Sandbox 就是它所在的房间——这个房间里有什么它就能碰到什么。图 8 Sandbox 决定了 Agent 能接触的世界边界于是 Agent 安全的一个重要原则出现尽可能通过环境边界限制能力而不能只靠 Prompt 告诉模型不要做危险的事情。假设你告诉模型千万不要读取 ~/.ssh这只是 Soft Constraint——模型可能遵守也可能因为误判、Prompt Injection、工具错误、上下文污染而执行危险操作。而如果 Sandbox 从操作系统层面就看不到 ~/.ssh那就是 Hard Constraint。所以 Agent 安全架构通常存在两种控制图 9 两种安全控制越接近执行层越可靠Permission本质是控制权分配第六个问题Agent 什么事情允许做这就是Permission。Sandbox 定义理论上能接触什么Permission 定义这一次允许做什么。比如 Sandbox 允许访问 /workspace执行rm -rf ./build系统可能允许执行git push系统可能要求人工确认。一个典型的权限分级读取文件自动允许、修改代码自动允许、执行测试自动允许、安装依赖要询问、访问互联网要询问、删除大量文件阻止、读取凭据阻止。而 Permission 的本质是控制权分配。Agent 系统的核心问题从来不只是AI 能不能做到还包括AI 应不应该自己做行为LLM程序人判断哪个文件相关✓选择调用搜索工具✓参数格式校验✓是否允许访问敏感目录✓删除生产数据✓✓是否接受最终方案✓一个成熟 Agent 系统最核心的能力之一就是把不同类型的控制权分配给最合适的主体。Claude Agent SDK 的权限系统已经支持 allow、deny、默认审批、Plan、dontAsk 等不同执行模式。这里有一个特别重要的设计工具被拒绝后拒绝结果会重新反馈给模型让 Agent 改变策略、寻找别的方案。权限系统因此不只是闸门它本身就是 Agent 所处环境的一部分。七、合起来一张全景图三层结构现在把六个问题放到一起我们终于可以画出一个比较完整的 Agent Harness图 10 Agent Runtime 全景六个问题串成一条执行链Session 沉淀一切这张图基本就是理解现代 Agent Runtime 的核心。而且这六个模块并不是平行关系更准确地说它们分成三层图 11 六个模块的三层归类认知 × 行动 × 治理其他能力都可以放回这张图有了这个框架很多概念突然就很好理解了概念它真正解决的问题RAGContext 从哪里来问题 2Memory哪些历史信息应该重新进入 Context问题 2 / 4CompactionContext 太长怎么办问题 2Skill如何把稳定经验提供给模型问题 2兼影响行为策略MCP外部 Tool 如何标准化接入问题 3Hook在 Agent Loop 的哪些节点插入确定性逻辑问题 1SubAgent是否把一部分任务放进独立 Context 与执行主体问题 1 / 2Workflow哪些控制权应该交回程序问题 6Human in the Loop哪些关键节点必须由人决定问题 6所以所谓复杂 Agent 架构其实只是围绕六个基本问题不断增加更高级的解决方案。回头再看 DeepSeek Harness 的目录结构也就顺理成章——agent-loop 解决问题 1context / system-prompt / compaction 解决问题 2tools / fs / shell / web / lsp 解决问题 3session / storage 解决问题 4sandbox / subprocess 解决问题 5interaction / guard 解决问题 6再往上叠加 skill、subagent、jobs、workflow、goal、plan。它不是一堆随机功能的堆砌而是在逐步构建一个完整的 Agent Runtime。八、什么时候才需要 Harness动态与确定的边界但完整 Runtime 并不意味着所有项目都需要它。如果应用只是用户问 KPI → LLM 判断查哪个指标 → 调一次查询工具 → 生成答案架构只需要 LLM Tool完全没必要上 Event Sourcing、SubAgent、Sandbox、Compaction。如果是每一步都很明确的固定流程Workflow 少量 LLM 节点可能比自由 Agent 更合适。一条重要原则只引入当前任务复杂度真正需要的 Runtime 能力。粗略判断如果任务执行步骤无法提前确定、需要反复观察环境、需要自主调用多个工具、执行时间较长、过程中可能失败、用户可能中途干预、需要暂停和恢复、具有真实副作用、需要权限控制和完整执行记录——Agent Runtime 的价值会越来越明显。反之如果步骤固定、输入输出清晰、风险高、强一致性要求、流程能提前定义更多控制权应该留在 Workflow / 程序手里。这引出本篇最值得记住的结论。传统 Workflow 里Program 决定下一步Agent 里Model 决定下一步。而现实中的优秀系统往往位于两者之间图 12 动态性与确定性的边界是 Agent 架构的核心判断因此未来真正优秀的 Agent 架构师需要掌握的能力并非怎么让所有事情都 Agent 化而是判断动态与确定的分界线。现在我们也可以给 Harness 一个更准确的定义了Agent Harness是模型与真实世界之间的运行时控制层。图 13 Harness 的本质一边是模型一边是真实世界这比把 Harness 理解成一个 Agent 框架更接近它真正的意义。也因此以后评价一个 Agent 系统不能只问用了什么模型还要问Context 怎么管理Loop 怎么设计Tool 如何治理长期 Session 如何保存执行环境如何隔离权限如何控制失败如何恢复如何支持人中途介入同一个模型放进不同 Harness最终形成的 Agent 能力可能差异非常大。未来最终的 Agent 能力会由一个乘积共同决定Model Capability × Harness Capability × Tool/Environment × Domain Knowledge结语 随身携带的六问检查表Agent 技术发展得很快每隔一段时间都会出现新概念RAG、MCP、Skill、Computer Use、SubAgent、Agent Team、Memory、Hooks、Workflow、Harness……跟着概念走很容易不断追热点。但从第一性原理看一个真正需要工作的 Agent始终逃不开六个问题。以后再看到一个新的 Agent 框架可以先别看它支持多少 Tool、多少模型、有没有 Multi-Agent先问六个问题这六个问题都能回答出来基本就理解了一个 Agent Runtime 的骨架。其他绝大部分能力都可以从这里继续生长出来。所以真正值得学习的并不是某一个框架今天提供了多少功能而是随着模型越来越强我们应该怎样设计模型外面的那套系统让智能真正能够稳定、安全、长期地运行。这才是 Agent Harness 真正值得研究的地方。
