Agent 系统不是一堆并列新词，而是运行底座、任务拓扑与执行循环逐层协作的操作系统式运行时。
导语
Agent 工程这两年最容易让人疲惫的地方，不是概念太难，而是新词总像一批批涌进来：Harness、Loop、Graph、Tool Use、Context Engineering、RAG、Orchestrator、多 Agent。每个词单独看都能解释，放在一起就开始打架。
一个更省力的理解方式，是先别把它们当成并列概念，而是把 Agent 看成一套正在成形的操作系统式运行时。
在这个视角里，Harness 不是 Graph 的竞争者，Graph 也不是 Loop 的替代品。它们处在不同层级：Harness 是运行底座，Graph 是组织方式，Loop 是最小执行闭环。Tool Use、RAG、Context 则更像系统调用、文件系统挂载和内存管理。
概念一旦放回层级里，很多争论会自动消失。真正的问题也会变清楚：当 Agent 开始管理权限、资源、状态、调度、上下文和外部副作用时，它就不能再只靠 prompt 工作，而必须具备一套类似操作系统的纪律。
图：Agent OS 视角下的运行底座、任务拓扑和执行循环
先看运行时
一个生产级 Agent 系统，通常不是“模型 + 工具”这么简单。
用户请求进入系统后，先被 Orchestrator 拆解和路由，再进入 Graph 或 Workflow。图里的不同节点可以是普通任务、Agent、人工确认点、审计节点、回退节点，也可以是一个自带试错能力的 Loop。
底层的 Harness / Runner 负责把这些节点跑起来：模型调用、上下文装配、工具网关、权限策略、日志、检查点、异常恢复都在这一层处理。外部工具、知识库、文件、数据库和网页，都不能裸露给模型直接碰，而要通过受控边界进入系统。
图：生产级 Agent 系统的运行时边界
这张图里最重要的不是节点数量，而是边界。
模型不是系统的全部。它负责推理和生成意图，但真实世界里的副作用要由 Harness 接管。Graph 不是单纯的流程图，它描述任务怎样分叉、并行、合并、暂停和回退。Loop 也不是完整系统，它只是一个节点内部的自主执行循环。
概念映射
把 Agent 系统类比成操作系统，不是为了套概念，而是为了找工程位置。
| 操作系统里的概念 | Agent 系统里的对应物 | 解决的问题 |
|---|---|---|
| 内核 / 运行时 | Harness / Runner | 权限、工具调用、日志、检查点、异常恢复 |
| 调度器 | Orchestrator | 多 Agent 调度、重试、取消、结果路由 |
| 进程 / 线程 | Agent / Sub-Agent | 状态边界、共享资源、并行与同步 |
| 系统调用 | Tool Use / Function Calling | 外部能力受控开放 |
| Cache / 虚拟内存 | Context Window / Context Compression | token 预算、信息分层、语义换页 |
| 文件系统挂载 | RAG / 外部知识库 | 外部知识按需接入 |
| 任务拓扑 | Graph / DAG / Workflow | 分支、并行、回退、人工断点 |
| 事件循环 | Loop / ReAct | 单任务试错、观察、继续或停止 |
这个映射能把一堆新词压成一条主线：
图：Agent OS 视角下的核心概念映射
如果只记一句话，就是：Harness 承载运行，Graph 编排多个节点和循环，Loop 负责单个 Agent 的自主迭代。
Agent 的状态边界
操作系统里，进程是资源边界，线程是执行单元。同一进程里的线程共享内存，跨进程通信必须显式进行。
这套机制放到 Agent 系统里，可以帮助我们理解多 Agent 协作为什么容易失控。一个 Agent 不应该只是一个 prompt。它应该有目标、权限、可访问资源、短期状态、长期记忆和生命周期。
多个 Sub-Agent 并行工作时，最难的不是“谁更聪明”，而是谁能访问什么状态、谁能写入结果、失败后如何回滚、取消信号怎么传播。
如果所有 Agent 共用同一个上下文，效率会高一些，但竞争条件也会出现：一个 Agent 覆盖另一个 Agent 的中间结论，两个 Agent 重复调用昂贵工具，或者某个未确认结果被后续节点当成事实继续使用。
如果每个 Agent 完全隔离，协作又会变慢，通信成本上升，很多信息需要反复传递。
所以，多 Agent 设计的重点不是拆得越细越好，而是先把边界写清楚：
· 哪些状态是私有的，哪些状态可以共享。 · 哪些结果必须通过消息显式传递。 · 哪些工具调用可以并发，哪些必须串行。 · 哪些写操作需要幂等键、锁或人工确认。 · Agent 失败后，谁负责撤销部分结果。
操作系统不会让进程随便读写彼此内存。成熟的 Agent 框架也不该让所有 Agent 默认共享所有上下文。
Tool Use 是系统调用
用户程序想访问硬件、网络或文件系统，必须通过系统调用。Agent 想搜索网页、运行代码、查数据库、发消息、修改文件，也不应该直接越过运行时。
Tool Use 的本质不是“给模型装插件”，而是给外部能力设置受控入口。
模型负责提出意图，例如查询订单、运行测试、创建文档。Harness 负责把意图变成真实调用，并处理参数校验、权限判断、执行、失败重试、结果截断和审计记录。
一个工程可用的工具系统，至少要回答这些问题：
| 问题 | 影响 |
|---|---|
| 输入 schema 是否明确 | 模糊参数会把错误推迟到执行阶段 |
| 是否区分只读和写入 | 权限模型决定风险边界 |
| 高风险动作是否确认 | 删除、发布、权限变更不能让模型直接执行 |
| 错误是否结构化返回 | 模型需要知道能不能恢复、怎么恢复 |
| 调用是否可审计 | 事后要能追溯用户意图、Agent 判断和执行结果 |
Function Calling 可以看成系统调用接口。Harness 则像内核态执行者。模型可以发起请求，但不能绕过内核直接碰外部世界。
Context 是昂贵缓存
Context Window 是 Agent 系统里最稀缺的资源。
它不是“能塞多少 token”的问题，而是系统如何判断什么信息留在近处，什么信息放到远处，什么信息需要压缩，什么信息可以丢掉。
操作系统有寄存器、CPU Cache、内存、磁盘和交换空间。Agent 系统也正在形成类似的层次：
| 记忆层级 | Agent 里的形态 | 使用方式 |
|---|---|---|
| 当前注意力 | 当前 prompt、最近消息 | 最快、最贵、最影响输出 |
| 工作记忆 | scratchpad、任务状态 | 保存推理过程和执行状态 |
| 压缩记忆 | 摘要、checkpoint | 提高密度，但会损失细节 |
| 外部记忆 | 文档、数据库、向量库 | 容量大，需要检索和校验 |
| 执行日志 | 工具调用记录、审计日志 | 适合复盘，不适合全量塞回上下文 |
当上下文满了，系统开始做 context compression。这很像虚拟内存里的分页和交换，只不过换出去的不是字节，而是语义。
压缩不是简单摘要。它在做几个判断：哪些约束必须保留原文，哪些工具结果只保留结构化字段，哪些推理过程可以被结论替代，哪些信息已经对当前目标无用。
所以，“把所有历史塞进上下文”不是工程能力。上下文更像昂贵的高速缓存，不是仓库。
真正的能力，是把信息分层，并设计清晰的载入、淘汰和压缩策略。
RAG 是文件系统挂载
RAG 常被说成“给模型接知识库”。这个说法没错，但容易让人误解成只要检索就够了。
从操作系统视角看，RAG 更像文件系统挂载：外部知识源被接到 Agent 的可访问空间里，需要时读取，不需要时不占用上下文。
这个类比能避开两个坑。
第一，RAG 不是把知识库全文塞进 prompt。真正有用的是按需加载，根据任务目标、查询意图、权限边界和新鲜度，只把必要片段放进当前工作集。
第二，RAG 不是无成本外挂。挂载文件系统要处理路径、权限、缓存、延迟、失效和卸载；RAG 也要处理索引质量、召回精度、来源引用、文档过期、访问权限和检索污染。
一个可靠的 RAG 系统，至少要满足几条底线：
· 检索片段能追溯来源。 · 结果能区分事实、观点、历史记录和生成摘要。 · 权限控制发生在检索前，而不是检索后再过滤。 · 高时效内容有更新时间，避免旧信息伪装成当前事实。 · 多来源结果可以合并、去重，并提示冲突。 · 任务结束后，不再需要的片段要从上下文里释放。
能访问很多知识，不代表每次推理都应该加载很多知识。
Graph 为什么重新变重要
Loop 是单个 Agent 的最小闭环：思考、行动、观察，再判断是否继续。它适合做 Demo，也适合处理边界清楚的小任务。
但复杂任务只靠一个 Loop 很快会出问题。路径不可控，失败要从头来，上下文越滚越大，多个任务难以并行，过程也不容易审计。
Graph 的价值，是把多个 Loop、普通节点、条件分支、人工断点和审计节点组织成网络。
| 层级 | 作用 | 工程意义 |
|---|---|---|
| Harness | 运行底座 | 让系统能执行、能恢复、能记录 |
| Graph | 编排拓扑 | 让任务能分支、并行、回退、审计 |
| Loop | 执行闭环 | 让单个 Agent 能自主试错和迭代 |
Graph 不是 Loop 的替代品。更准确地说，Loop 是最简单的循环图，Graph 是很多 Loop 与其他控制节点组合后的执行网络。
一张 Graph 里可以有编码 Loop、测试 Loop、评审 Loop、监控 Loop。它们既能协作，也能互相制衡。比如编码节点产出补丁，测试节点验证，评审节点查风险，失败后只回退到局部节点，而不是整条链路从头再来。
这就是 Graph Engineering 真正解决的问题：把单个 Agent 的自主性放进可控的系统拓扑里。
Agent 开发的几个判断
先定义边界，再写 prompt。Agent 的职责、输入、输出、权限、状态和失败处理，比一句精巧提示词更重要。
把工具调用当成特权接口。只读、低风险写入、高风险写入必须分层，删除、发布、权限变更要有人类确认或明确门禁。
把上下文当缓存，不要当仓库。长期知识、历史日志和附件应放在外部存储里，按需检索和压缩，而不是全量塞进 prompt。
RAG 必须带来源。没有来源、时间和权限信息的检索结果，很难在工程上被信任。
调度器要负责停下来。权限不足、目标冲突、高风险动作、上下文不足、外部系统异常，都应该触发暂停、降级或人工判断。
复杂任务要建模成 Graph。任务依赖、工具调用、RAG 证据、上下文压缩、多 Agent 消息和失败回退，都应该能被追踪，而不是散落在一段线性日志里。
结语
Agent 领域的新词还会继续出现。逐个追词，会越追越乱；按运行时分层看，很多概念会自动归位。
底层是 Harness，负责安全、权限、工具、日志、检查点和恢复。中间是 Graph，负责把任务组织成可分支、可并行、可回退、可审计的拓扑。内部跑着一个个 Loop，让单个 Agent 能试错、观察和迭代。
Tool Use、Context、RAG 不是额外装饰，而是这套运行时要
