2024 年 90% 的 Agentic RAG 项目在生产环境失败，这一数据来自 Composio 的调研。失败原因并非模型能力不足，而是缺乏系统性的架构控制。Veso AI 提出的 "Agentic Harness" 概念 —— 将控制平面与 LLM 分离，通过四层架构（Context Engineering、Tool Layer、Data Layer、Output Layer）实现确定性治理 —— 为这一问题提供了工程化答案。本文从这一实践出发，构建代理架构模式的分类体系（taxonomy），明确各模式的选型逻辑与落地参数。
一、代理架构的六大核心模式
基于 Veso AI 的生产实践与 Anthropic 的工程定义，代理系统可归纳为六大互相关联的模式。这些模式并非孤立存在，而是构成从输入到输出的完整控制链。
1. 规划 - 执行分离模式（Planning-Execution Separation）
该模式将任务分解与动作执行解耦。规划层负责意图理解、子任务拆分与依赖排序，执行层负责工具调用与状态更新。Veso AI 的 "Deterministic First, LLM Second" 原则体现了这一分离：能用代码计算的部分（向量检索、图谱查询、schema 校验）绝不交给模型，仅将需要判断力的环节（查询分解、结果重排序、叙事合成）留给 LLM。这一分离可将每查询的 token 消耗降低 60-80%，同时缩小幻觉暴露面。
2. 反思循环模式（Reflection Loop）
反思不是事后总结，而是嵌入执行流程的实时评估。Anthropic 的长运行代理研究提出双代理架构：初始化代理设置状态工件（特性列表、进度日志、代码仓库），编码代理增量执行。关键在于，代理需要在上下文窗口刷新时快速理解工作状态 —— 这由 harness 维护结构化状态工件实现，而非依赖模型记忆。生产环境中，反思模块通常以独立评估器（evaluator）形式存在，对比输出与意图，触发重新规划或自适应调整。
3. 多智能体编排模式（Multi-Agent Orchestration）
当单代理无法覆盖复杂任务时，需要多代理协作。常见编排结构包括：
- 分层树形（Hierarchical）：顶层管理者制定策略，中层监督者翻译为计划，底层工作者执行任务
- 分派 - 集群（Dispatcher-Swarm）：分派器将请求路由至专业代理，支持双向通信进行批判与细化
- 分合并行（Split-and-Merge）：协调器将任务拆分为并行子任务，分发至多代理，再合并结果
Cursor 的实践表明，不同模型对同一提示的响应差异显著 —— 有的偏好grep而非语义搜索，有的需要显式的 lint 指令。因此，多代理编排需支持模型特定的 harness 配置，而非假设模型可互换。
4. 工具权限门控模式（Tool Permission Gating）
工具不是开放访问的。Claude Code 采用 19 个权限门控工具，每个工具位于权限门后，harness 强制执行每工具调用限制与超时。这一模式确保失控代理以 "失败闭合"（fail closed）方式终止，而非持续消耗预算。关键参数包括：每工具最大调用次数（通常 3-5 次）、单次调用超时（5-30 秒）、工具间依赖声明。
5. 上下文工程模式（Context Engineering）
Anthropic 将上下文工程定义为：寻找最小的高信号 token 集以最大化期望结果概率。Veso AI 通过 Domain Primer 实现这一点 —— 在启动时（或数据变更时）构建领域实体、关系、schema、关键约束的压缩结构化摘要，注入每次 LLM 提示。典型 primer 包含：实体列表（组织、文档、人员）、关系图谱、schema 定义（节点标签、块数量、向量索引维度）。这一做法可减少 30-50% 的工具调用需求，因为模型在首次调用前已理解领域结构。
6. 状态管理跨窗口模式（State Management Across Context Windows）
长运行代理面临上下文窗口限制。Devin 的解决方案是：维护隔离的云环境（终端、编辑器、浏览器），在受控沙箱内运行代理循环，支持分叉与回滚、机器快照、异步会话交接。状态管理的核心是结构化工件（如特性列表、进度日志、记忆索引），而非依赖模型的隐含记忆。Claude Code 的后台守护进程autoDream在 24 小时不活动后唤醒，读取项目记忆目录，整合学习、删除矛盾、重写记忆索引 —— 这是 harness 的职责，而非模型的能力。
二、模式选型矩阵与权衡
六大模式并非必须全部采用，需根据任务复杂度、延迟要求、成本预算进行组合。以下是选型矩阵：
| 模式 | 适用场景 | 复杂度 | 延迟影响 | 成本影响 | 关键风险 |
|---|---|---|---|---|---|
| 规划 - 执行分离 | 任何非 trivial 任务 | 中 | +10-20% | -60-80% token | 分离边界模糊导致重复推理 |
| 反思循环 | 需要自我修正的长任务 | 高 | +30-50% | +20-40% token | 过度反思导致循环停滞 |
| 多智能体编排 | 跨领域复杂任务 | 很高 | +50-100% | +100-300% | 协调开销超过并行收益 |
| 工具权限门控 | 任何工具使用场景 | 低 | 可忽略 | 可忽略 | 权限配置错误导致功能受限 |
| 上下文工程 | 领域固定场景 | 中 | -20-30% | -30-50% token | primer 维护成本 |
| 状态跨窗口 | 长会话 / 异步任务 | 高 | 可忽略 | + 存储成本 | 状态不一致 |
选型建议：
- MVP 阶段：采用规划 - 执行分离 + 工具权限门控。以确定性层处理 80% 的常规路径，仅将边界情况交给 LLM，同时设置硬性调用限制防止失控。
- 生产阶段：增加上下文工程与反思循环。通过 Domain Primer 提升首次准确率，通过反思循环实现有限度的自我修正（建议最大反思轮次为 2）。
- 复杂场景：引入多智能体编排与状态跨窗口管理。仅在任务天然可并行化（如文档多章节并行处理）或需要跨领域协作时启用多代理，避免为复杂性而复杂性。
三、可落地的实现参数
基于 Veso AI 与 Anthropic 的生产数据，以下是可直接采用的参数清单：
Turn Budget（轮次预算）
- 最大轮次：5-10 轮
- 强制合成轮次：倒数第二轮（penultimate turn）
- 优雅降级：预算耗尽时回退至确定性结果而非静默失败
Token 与上下文
- Domain Primer 构建频率：启动时 + 数据变更时
- 块去重：维护
_seen_chunk_ids防止重复检索 - 会话级 token 预算追踪：硬限制 + 软预警
工具治理
- 每工具最大调用：3-5 次
- 单次调用超时：5-30 秒（根据工具类型）
- 权限门：显式声明而非提示约束
输出分离
- 终端工具模式：
compose_response强制声明叙事与数据边界 - 引用映射：每声明映射回原始块 ID
- 结构化数据通道：直接透传，不经 LLM 重写
多代理协调
- 代理间通信协议：结构化 JSON，包含
from_agent、to_agent、message_type、payload - 批判轮次：每子任务最多 1 轮批判 + 1 轮修订
- 协调器超时：子任务并行等待上限 60 秒
四、从 RAG 到 Harness 的演进逻辑
Veso AI 总结了四年演进路径：2023 年 RAG（"把文档给 LLM"）→ 2024 年 Agents（"让 LLM 使用工具"）→ 2025 年 Agent Swarms（"让代理协调"）→ 2026 年 Harnesses（"控制代理能做什么、能看到什么、能输出什么"）。
模型吸收了多代理框架约 80% 的能力，剩余 20%—— 持久化、确定性重放、成本控制、可观测性、错误恢复 —— 正是 harness 的职责。竞争壁垒不再是 API 密钥，而是编排层。
对于企业而言，这意味着 AI 项目必须从 "科学实验" 转向 "产品问题"。构建 harness，在数据层约束领域，分离事实与叙事，赋予某人发布的权限。模型是可替换组件，harness 才是产品。
参考来源
- Veso AI: "The Agentic Harness: Why the Orchestration Layer Is the Product" (2026)
- Anthropic Engineering: Long-running agent research on harness architecture
- Composio: 2024 Agentic RAG production failure statistics
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。