AI Agent 架构设计全景图:5 大维度 + 5 种经典模式,终结选型焦虑

❝

• 论文标题: Architectural Design Decisions in AI Agent Harnesses
• 论文链接: https://arxiv.org/abs/2604.18071v1
• 代码链接: 暂无
• 发表会议: arxiv

❞

当 AI Agent 从演示走向生产，决定成败的往往不是大模型本身，而是围绕它的那套 “脚手架” 工程。工具调用、上下文管理、多 Agent 协调、安全隔离… 这些非 LLM 的基础设施被统称为 “Agent Harness”。最近一项覆盖 70 个主流 Agent 项目的系统性研究，首次完整绘制了 Agent Harness 的设计空间地图，揭示了那些被反复验证的架构规律和常见误区。看完这篇，你再也不用在 LangChain、CrewAI、OpenHands 之间盲目选型了！

一、什么是 Agent Harness？

在深入研究之前，我们必须先明确一个核心概念 —— 「Agent Harness（智能体驾驭工程）」。

具体可以定义为「围绕 LLM 智能体行为的非 LLM 工程层」，它负责打包工具中介、上下文处理、任务委派、安全控制和流程编排等核心功能。

简单来说，如果把 LLM 比作 Agent 的 “大脑”，那么 Agent Harness 就是 Agent 的 “骨骼、肌肉和神经系统”。它决定了 Agent 如何与外部世界交互、如何记住过去的事情、如何分解复杂任务、如何安全地执行操作，以及如何与其他 Agent 协作。

需要注意的是，”Harness” 只是一个方便分析的统称，这些基础设施在实际项目中可能以框架、平台、CLI 工具、运行时等多种形式出现。

二、为什么我们需要研究 Agent Harness 架构？

过去两年，AI Agent 领域爆发式增长，涌现出了 LangChain、AutoGPT、CrewAI、OpenHands 等数十个知名项目。然而，这个领域长期存在三个痛点：

• 「缺乏统一的架构语言」：不同项目使用不同的术语描述相似的功能，导致开发者难以比较和选择
• 「设计决策碎片化」：很多架构选择是基于直觉而非实证，开发者经常重复踩坑
• 「能力与治理脱节」：很多项目只关注功能实现，忽视了安全隔离、审计和可运维性

为了解决这些问题，研究人员对 70 个公开可用的 Agent 系统项目进行了协议引导、源码驱动的实证研究，回答了三个关键问题：

• 哪些设计决策维度在不同项目中反复出现？
• 这些决策之间存在哪些共现关系？
• 不同复杂度和定位的项目通常会选择哪些典型的架构组合？

三、Agent Harness 的五大核心设计维度

研究人员通过深入分析 70 个项目的源代码和技术文档，识别出了五个反复出现的核心设计维度，每个维度都包含多个可选的实现方案。

3.1 子 Agent 架构：如何分解任务？

子 Agent 架构决定了一个框架是保持单 Agent 结构，还是通过额外的 Agent 实例来分解任务。

「关键发现」：

• 30% 的项目仍然采用单 Agent 架构，适合简单任务
• 编排器 – 工作者和基于工具的委派是最常见的多 Agent 模式
• 很多声称支持深度递归的项目，在源码中实际上都设置了明确的深度限制

3.2 上下文管理：如何记住过去？

上下文管理是 Agent 系统中最关键也最容易被忽视的部分，它决定了 Agent 如何保留、压缩和重用历史信息。

「关键发现」：

• 纯依赖 LLM 上下文窗口的系统非常罕见（仅 4.3%）
• 混合式和文件持久化是最主流的方案，占比超过 50%
• 大多数成熟项目都实现了显式的 token 预算管理，而不是简单地截断历史

3.3 工具系统：如何扩展能力？

工具系统决定了 Agent 如何定义、注册、发现和执行外部工具，是 Agent 与外部世界交互的桥梁。

关键发现：

• 显式注册表仍然是最主流的工具注册方式（34.3%）
• 基于模型上下文协议 (MCP) 的工具系统正在快速崛起，占比达到 14.3%
• 工具注册方式与项目的生态野心高度相关：平台型项目更倾向于 MCP 或插件系统

3.4 安全机制：如何控制风险？

安全机制决定了 Agent 如何约束危险操作、隔离执行环境并记录操作轨迹，是 Agent 走向生产的关键。

隔离级别分布：

审计能力分布：

关键发现：

• 中间级别的隔离（进程 + 容器）占主导地位，达到 76%
• 高保障审计非常罕见，仅 5% 的项目实现了防篡改审计
• 40% 的项目完全没有审计能力，这是当前 Agent 安全的最大短板

3.5 编排机制：如何组织执行？

编排机制决定了 Agent 如何随时间结构化任务执行，包括工作流定义和规划策略两个方面。

「关键发现」：

• ReAct 风格的推理 – 执行循环仍然是最主流的规划策略（50%）
• 事件驱动的编排方式正在快速增长，占比达到 30%
• 声明式工作流更适合需要可重复性和可审计性的企业场景

四、设计决策的共现与非共现规律

研究最有价值的部分在于揭示了不同设计决策之间的关联关系，打破了很多常见的误解。

4.1 三大强共现关系

研究人员使用支持度、置信度和提升度三个指标来衡量决策之间的关联强度：

其中提升度大于 1 表示两个决策倾向于同时出现，小于 1 表示倾向于不同时出现。

共现关系 1：子 Agent 复杂度 ↔ 上下文管理复杂度

• 支持度：0.73
• 提升度：1.8
• 解释：多 Agent 结构会显著增加状态共享的压力。没有子 Agent 的项目平均上下文管理得分为 2.8，而编排器 – 工作者模式的项目平均得分为 4.1，多级递归模式的项目平均得分为 4.2。

共现关系 2：执行隔离强度 ↔ 安全控制完善度

• 支持度：0.89
• 提升度：3.4
• 解释：100% 使用容器隔离的项目都实现了策略引擎，而没有容器隔离的项目中只有 23% 实现了策略引擎。执行能力越强，对治理的需求就越高。

共现关系 3：工具注册标准化 ↔ 生态系统野心

• 支持度：0.62
• 提升度：2.8
• 解释：MCP 优先的项目平均工具发现得分为 4.62，而注册表中心的项目平均得分为 3.86，极简工具系统的项目平均得分为 2.81。更正式的扩展边界通常意味着更广泛的生态系统愿景。

4.2 三大重要非共现关系

这些 “不存在” 的关系同样重要，它们打破了很多行业内的刻板印象。

非共现关系 1：编程语言不决定架构模式

• 高级子 Agent 模式在不同语言中的占比：TypeScript 40%，Python 42%，Rust 57%，Go 43%
• 解释：语言选择主要影响实现细节，而不是高层架构。同样的架构模式可以用不同的语言实现。

非共现关系 2：用例不决定设计复杂度

• 同样是 “编码助手” 用例，既有轻量级的本地工具，也有完整的企业级执行平台
• 同样是 “通用助手” 用例，既有极简的单 Agent 实现，也有复杂的多 Agent 编排系统
• 解释：架构选择更多是战略决策，而不是由用例自动决定的。

非共现关系 3：能力增长不自动带来安全成熟度

• 一些拥有广泛工具表面和深度编排能力的项目，仍然只保留了最基本的安全控制
• 一些能力相对有限的项目，反而在安全设计上投入了更多精力
• 解释：安全是一个需要主动投资的领域，不会随着功能增长自动出现。

五、五种典型的 Agent Harness 架构模式

基于对 70 个项目的分析，研究人员总结出了五种反复出现的典型架构模式，每种模式都有其适用场景和权衡。

5.1 轻量级工具模式

• 复杂度：低
• 定位：个人工具、快速原型、单一用途助手
• 核心设计：单 Agent 架构 + 内存 / 简单文件持久化 + 硬编码 / 装饰器工具 + 无沙箱 + 命令式控制流
• 代表项目：subzeroclaw, shrew, babyclaw
• 优势：架构简单、部署快速、运行开销小
• 劣势：不支持复杂任务分解、缺乏持久化和安全控制

5.2 平衡 CLI 框架模式

• 复杂度：低到中
• 定位：开发者面向的命令行助手、编码工具、可扩展生产力框架 核心设计：基本 / 工具委派子 Agent + 文件持久化 + MCP 优先 / 装饰器工具 + 进程级沙箱 + 声明式配置
• 代表项目：openclaw, fast-agent, kimi-cli
• 优势：在可扩展性和可部署性之间取得了良好平衡
• 劣势：不支持深度子 Agent 层次和企业级治理

5.3 多 Agent 编排器模式

• 复杂度：中到高
• 定位：复杂自动化框架、协作编码系统、研究工作流引擎
• 核心设计：编排器 – 工作者 / 递归子 Agent + 分层 / 混合内存 + 结构化工具委派 + 基于策略的安全 + 容器 / WASM 沙箱
• 代表项目：claude-code-src, docker-agent, agentpool
• 优势：强大的任务分解和协调能力
• 劣势：上下文管理和安全设计复杂度高

5.4 企业级全功能模式

• 复杂度：高
• 定位：生产部署、安全敏感系统、企业集成、合规导向平台
• 核心设计：多级递归 / 事件驱动子 Agent + 企业级向量数据库内存 + 完整 MCP 生态 + 多层防御安全 + 插件架构
• 代表项目：openhands, openfang, nullclaw
• 优势：高安全性、高可扩展性、完整的治理能力
• 劣势：基础设施和治理成本高

5.5 场景垂直化 / 研究导向模式

• 复杂度：可变
• 定位：学术研究、算法原型、特定领域工作流系统
• 核心设计：高度定制化的子 Agent 和内存系统 + 最小化工具实现 + 通常缺乏安全机制 + 专注于特定领域能力
• 代表项目：autoresearchclaw, deer-flow, deepagents
• 优势：快速实验、特定领域深度优化
• 劣势：通用性和操作鲁棒性差

六、给开发者和架构师的实用建议

基于这项研究的发现，论文给出了四条非常实用的设计和选型建议：

• 「尽早定义目标复杂度范围」

• 轻量级个人工具、开发者 CLI、研究工作流引擎和企业平台需要完全不同的架构承诺
• 不要一开始就追求 “大而全”，架构复杂度应该与目标场景匹配

• 「选择连贯的设计组合，而不是孤立的功能」

• 深度任务分解通常需要更明确的上下文持久化
• 开放式工具扩展通常需要更清晰的执行边界和审批逻辑
• 架构一致性比最大化功能数量更重要

• 「评估适配性而不是抽象的先进性」

• 没有 “最好” 的架构，只有 “最适合” 的架构
• 选择框架时，要考虑其协调深度、持久化模型、可扩展性方法和安全姿态是否与你的工作流需求匹配

• 「将安全和可操作性作为一等设计关注点」

• 更强大的执行能力需要更完善的治理机制
• 沙箱边界、审批流程和审计可见性应该与工具执行和工作区访问同时设计

七、总结

这项研究是 AI Agent 领域第一个系统性的架构实证研究，它将我们对 Agent 系统的理解从 “零散的框架示例” 提升到了 “结构化的设计空间”。

它告诉我们，Agent Harness 不仅仅是 LLM 的 “包装纸”，而是一个具有自身内在规律和设计原则的独立工程领域。随着 Agent 技术从演示走向生产，对这些架构规律的理解将变得越来越重要。

未来的 Agent 系统将不再是单一的大模型，而是由 LLM、工具系统、编排引擎、安全控制和上下文管理组成的复杂分布式系统。掌握这些架构设计原则，将是每一个 AI 工程师在 Agent 时代的必备技能。

欢迎大家加入LLM技术交流群：