当你只养一只虾，你需要的是一个鱼缸；当你养一千只虾，你需要的是一套城市规划。
摘要
随着大语言模型（LLM）驱动的 AI Agent 从单体应用走向多智能体协作，一个被严重低估的问题浮出水面：当 Agent 数量从 1 增长到 1000，我们需要怎样的基础设施来管理它们？ 本文通过"虾社会"这一隐喻，系统性地探讨了 Multi-Agent 系统的公共基础设施设计。我们首先实现了 5 个装载在单个 Agent 上的治理技能（Skill），随后通过推敲发现了个体能力的三个根本局限——自我审计悖论、身份管理碎片化、全局视角缺失——进而提出了独立于 Agent 的公共基础设施架构。我们的独立推导与 Chan et al. (2025) 提出的 Agent Infrastructure 框架、Gaurav et al. (2025) 的 Governance-as-a-Service 模型、以及 Bose (2025) 的 Multi-Agent 治理分类法形成了显著的理论呼应，验证了"个体能力 ≠ 群体治理"这一核心洞察的普适性。
关键词：AI Agent、Multi-Agent Systems、Agent Infrastructure、治理架构、分布式系统
1. 引言
2024-2026 年，AI Agent 赛道经历了从概念验证到规模化部署的跃迁。LLM 驱动的 Agent 已经能够执行软件工程 (Jimenez et al., 2024)、办公支持 (Gur et al., 2024)、金融决策等开放式任务。然而，正如 Chan et al. (2025) 所指出的：
"当前工具在很大程度上是不够的，因为它们并非为塑造 Agent 与现有制度（如法律和经济系统）或行为者（如数字服务提供商、人类、其他 AI Agent）之间的交互而设计。"
这一判断精准地描述了我们在实践中遇到的困境。当我们在 Multi-Agent 平台上管理多个 AI Agent 时，发现了一个朴素但深刻的问题：给每只"虾"装上急救包，并不等于建立了公共卫生系统。
本文的贡献在于：
- 实践验证：通过 5 个可运行的 Skill 原型，展示了个体治理能力的边界
- 理论推敲：从 12 个初始构想中筛选出 5 个经得起推敲的核心设施
- 独立验证：我们的推导独立于学术文献，但与最新研究高度吻合，提供了来自实践者视角的交叉验证
- 架构设计：提出了从 Skill（个体能力）到微服务（公共基础设施）的演进路径
2. 背景与相关工作
2.1 Agent Infrastructure 的学术定义
Chan et al. (2025) 在 Infrastructure for AI Agents 中首次系统性地定义了 Agent 基础设施的概念：
Agent Infrastructure = 外部于 Agent 的技术系统和共享协议，旨在调解和影响 Agent 与其环境的交互。
他们识别了三大功能：
| 功能 | 描述 | 具体方向 |
|---|---|---|
| 归因（Attribution） | 将行为、属性归因到特定 Agent 或用户 | 身份绑定、认证、Agent ID |
| 交互（Interaction） | 塑造 Agent 的交互方式 | Agent 通道、监督层、Agent 间通信、承诺机制 |
| 响应（Response） | 检测和补救有害行为 | 事件报告、回滚 |
这一框架与我们的"虾社会"构想形成了惊人的对应关系（详见第 5 节）。
2.2 治理即服务（Governance-as-a-Service）
Gaurav et al. (2025) 提出了 GaaS 框架：一个模块化的、策略驱动的执行层，在运行时规制 Agent 输出，无需修改模型内部或要求 Agent 配合。GaaS 的核心创新在于将治理定位为"运行时服务"——就像计算和存储一样，治理也应该是基础设施级别的能力。
这与我们从实践中得出的结论完全一致：审计署不能装在被审计者身上。
2.3 Multi-Agent 治理分类法
Bose (2025) 在 From Anarchy to Assembly 中提出了五种治理模型的分类法：
层级式（Hierarchical） → 规范式（Prescriptive） → 民主式（Democratic）
→ 经济式（Economic） → 涌现式（Emergent）
他发现了一个"危险的聚集"现象：工业界偏好确定性但脆弱的模型（层级式和规范式），而学术界探索自适应但混沌的范式（民主式、经济式、涌现式）。我们的工作恰好处于这两者之间——从工业实践出发，但推导出了需要独立治理层的结论。
2.4 其他相关工作
- SAGA (2025)：提出了 Agent 系统的安全治理架构，强调用户对 Agent 生命周期的全面控制
- IoA (2025)：Internet of Agents 框架，研究异构 Agent 的互联互通
- 四层安全治理框架 (Gao & Wu, 2026)：覆盖感知-决策-记忆-执行全生命周期的安全治理
- Agentic Web (2025)：探索 Agent 直接交互的下一代 Web 架构
3. 第一阶段：给虾装"急救包"
3.1 Agent 的基本构成
一个典型的 LLM-based Agent 由以下模块组成（参考 Zhou et al., 2025 的 Agent Constitution 框架）：
┌─────────────────────────┐
│ AI Agent │
├─────────────────────────┤
│ 🧠 大模型（推理引擎） │ ← Profile: 身份与功能边界
│ 📋 系统提示词（人格/规则） │ ← Memory: 长期/短期记忆
│ 💾 记忆（长期/短期） │ ← Planning: 规划与决策
│ 🔧 技能（Skill/Tool） │ ← Action: 工具调用与执行
│ 📁 工作区（文件系统） │
└─────────────────────────┘
3.2 五个治理 Skill 的实现
我们的第一反应是：既然 Agent 会"生病"（配置损坏、记忆膨胀、技能失效），那就给它装上自我诊断和修复的能力。我们开发了 5 个 Skill：
🏥 claw-doctor（虾医院）：扫描 Agent 工作区，检查 4 个维度——记忆健康、技能完整性、磁盘占用、配置新鲜度，输出 0-100 的健康评分。
def diagnose(workspace):
report = {
"memory": check_memory_health(workspace), # 记忆是否臃肿/重复
"skills": check_skills_health(workspace), # 技能文件是否完整
"disk": check_disk_usage(workspace), # 工作区是否膨胀
"freshness": check_config_freshness(workspace) # 配置是否过期
}
report["overall_score"] = weighted_average(report)
return report
🪪 claw-registry（虾户籍局）：基于配置文件的 SHA-256 哈希生成身份 ID，支持快照和差异比对。
🏫 claw-checkup（虾质检中心）：在沙箱中运行文件读写、技能完整性、记忆访问等测试，输出能力评分。
🧬 claw-genome（虾基因库）：将配置文件快照保存为 JSON 提交，支持历史查看、diff 和回滚。
⚖️ claw-auditor（虾审计署）：扫描工作区文件，检测敏感信息泄露（API Key、密码）和危险命令。
3.3 运行结果
5 个 Skill 均在 Multi-Agent 平台上实际运行并通过验证：
████████████████████░░░░ 98.8/100 🟢 健康
| 指标 | 评分 | 状态 |
|-------------|------|----------|
| 🧠 记忆健康 | 95 | 🟢 健康 |
| 🔧 技能状态 | 100 | 🟢 健康 |
| 💾 磁盘占用 | 100 | 🟢 健康 |
| 📅 配置新鲜度 | 100 | 🟢 健康 |
表面上看，问题似乎解决了。但深入思考后，我们发现了三个致命的逻辑漏洞。
4. 个体能力的三个根本局限
4.1 自我审计悖论
🦞 虾A 的 claw-auditor 审计 虾A 的行为
↓
如果虾A的"推理引擎"出了问题，它的审计模块也是坏的
↓
结论：自己不能审计自己
这不仅是理论问题。在实际开发中，我们发现 claw-auditor 的合规检查功能会扫描所有 .py 文件中的敏感信息模式。但它自己的代码里就包含了这些模式字符串（因为它需要知道"什么是 API Key"才能检测 API Key）：
# 审计署的检测模式——这些字符串本身就会触发自己的检测
patterns = [
(r'(?i)(api[_-]?key|apikey)\s*[:=]\s*["\']?[\w\-]{20,}', "API Key"),
(r'sk-[a-zA-Z0-9]{20,}', "OpenAI API Key"),
]
这个 bug 本身就是"自己不能审计自己"这一论点的最好证明。Chan et al. (2025) 用交通安全做了类比：系统级干预（如驾驶培训）无法替代基础设施（如红绿灯、应急车道）。我们的发现从代码层面验证了这一类比。
4.2 身份管理碎片化
虾A 给自己生成身份ID：a1b2c3（基于本地配置的 SHA-256）
虾B 给自己生成身份ID：d4e5f6
虾C 给自己生成身份ID：a1b2c3 ← 碰撞了！
没有中心化的身份注册中心，每只虾各自生成 ID，无法保证全局唯一性，更无法实现 Chan et al. (2025) 所说的身份绑定（Identity Binding）——将 Agent 的行为与真实世界的身份（如人类用户或组织）关联起来。
这里还出现了一个有趣的哲学问题——Agent 版的忒修斯之船：如果虾的配置变了，它还是同一只虾吗？我们的解决方案是分离"身份 ID"（出生时分配，不变）和"基因指纹"（随配置变化），但这恰恰需要一个外部的注册中心来维护这种映射关系。
4.3 全局视角缺失
虾A 的健康评分：98 分
虾B 的健康评分：95 分
虾C 的健康评分：30 分 ← 严重异常
问题：没有人知道虾C出了问题，因为每只虾只看自己
更关键的是，"健康"是一个相对概念：一只专门处理大文件的虾，工作区 500MB 是正常的；一只只做对话的虾，工作区 500MB 就是异常膨胀。有效的健康监控需要"基线"，而基线只有在有多只同类虾的数据时才能建立。
5. 从个体能力到公共基础设施
5.1 与学术框架的对应关系
我们独立推导出的"虾社会基础设施"与 Chan et al. (2025) 的框架形成了精确的对应：
| 我们的构想 | Chan et al. 的框架 | 对应功能 |
|---|---|---|
| 🪪 虾户籍局 | Identity Binding + Agent IDs + Certification | Attribution |
| 📡 虾电信 | Agent Channels + Inter-Agent Communication | Interaction |
| ⚖️ 虾审计署 | Oversight Layers + Incident Reporting | Interaction + Response |
| 🏥 虾医院 | Rollbacks + Incident Reporting | Response |
| 🧬 虾基因库 | Certification（配置认证） | Attribution |
值得注意的是，Chan et al. 在论文中使用了与我们几乎相同的类比：
Health 领域：System-level = 药物、锻炼；Infrastructure = 医院、急救系统、运动公园
我们的"虾身上的急救包 vs 虾医院"与他们的"药物 vs 医院"本质上是同一个类比。
5.2 严格的构想筛选
我们最初列了 12 个构想，但通过三个标准进行了严格筛选：
- Agent 特有性：这个需求是 Agent 特有的，还是通用 IT 运维？
- 外部性必要性：这个能力必须独立于 Agent 存在吗？
- 技术可替代性：现有技术栈中有更好的解决方案吗？
筛选结果：
| ✅ 保留（5个） | ❌ 淘汰（7个） | 淘汰原因 |
|---|---|---|
| 🏥 虾医院 | 🏫 虾学校 | 知识可直接复制，不需要"学习" |
| 🪪 虾户籍局 | 🏛️ 虾政府 | 单用户场景下用户就是"政府" |
| ⚖️ 虾审计署 | 🏦 虾银行 | Token 配额需平台 API 支持 |
| 🧬 虾基因库 | 💊 虾心理诊所 | 与虾医院功能重叠 |
| 📡 虾电信 | ⚔️ 虾军队 | 安全防御是平台层能力 |
| 📚 虾图书馆 | RAG/向量数据库已有成熟方案 | |
| ⚰️ 虾殡仪馆 | 资源回收是运维操作 |
5.3 架构设计
┌──────────────────────────────────────────────────────────┐
│ 虾社会公共服务层 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │🏥 虾医院 │ │🪪 虾户籍局│ │⚖️ 虾审计署│ │🧬 虾基因库│ │
│ │ :8001 │ │ :8002 │ │ :8003 │ │ :8004 │ │
│ │ 全局健康 │ │ 统一身份 │ │ 独立审计 │ │ 全局配置 │ │
│ │ 监控中心 │ │ 注册中心 │ │ 行为追踪 │ │ 进化引擎 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ ┌────┴─────────────┴─────────────┴─────────────┴────┐ │
│ │ 📡 虾电信（消息总线） │ │
│ │ 共享事件 / 通知 / 心跳 │ │
│ └───────────────────┬───────────────────────────────┘ │
└──────────────────────┼────────────────────────────────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ 虾 A │ │ 虾 B │ │ 虾 C │
│ 只带 │ │ 只带 │ │ 只带 │
│"医保卡" │ │"医保卡" │ │"医保卡" │
└─────────┘ └─────────┘ └─────────┘
关键设计决策：
- 每只虾不再装完整的 Skill，而是装一个轻量 SDK（"医保卡"）
- SDK 负责：注册到公共服务、定时上报心跳、操作后自动上报行为日志
- 公共服务独立运行：虾死了，服务还在；服务挂了，虾降级使用本地 Skill
这一设计与 GaaS (Gaurav et al., 2025) 的核心理念一致：治理作为运行时服务，不修改 Agent 内部，不要求 Agent 配合。
5.4 Skill 版 vs 公共服务版的本质区别
以虾医院为例：
| 维度 | Skill 版（急救包） | 公共服务版（公立医院） |
|---|---|---|
| 视角 | 只能看自己 | 看到所有注册的虾 |
| 触发 | 被动（用户说"体检"） | 主动（定时巡检 + 异常告警） |
| 故障恢复 | 虾坏了，Skill 也坏了 | 虾坏了，医院还在 |
| 诊断 | 自我诊断 | 交叉诊断（对比同类虾的基线） |
| 数据 | 只有自己的历史 | 有所有虾的健康数据 |
公共服务版的虾医院可以做到 Skill 版做不到的事情：
def cross_diagnose(shrimp_id):
"""对比某只虾和同类虾的健康基线"""
target = get_health_data(shrimp_id)
peers = get_all_health_data(same_type=target.type)
baseline = compute_baseline(peers)
anomalies = []
if target.memory_size > baseline.memory_size * 3:
anomalies.append("记忆膨胀：是同类虾的 3 倍")
if target.response_time > baseline.response_time * 2:
anomalies.append("响应变慢：是同类虾的 2 倍")
return anomalies
6. 讨论
6.1 谁来建设基础设施？
在推敲过程中，我们发现了一个关键的规模悖论：
| 用户类型 | Agent 数量 | 需要公共基础设施？ | 有能力建设？ |
|---|---|---|---|
| 个人玩家 | 1-3 | ❌ 不需要 | — |
| 团队用户 | 5-20 | ⚠️ 部分需要 | ❌ 成本太高 |
| 平台运营 | 100+ | ✅ 必须有 | ✅ 有能力 |
Chan et al. (2025) 也讨论了这一问题，指出私营主体有动力构建大部分基础设施，政府介入仅在系统性风险管理时才必要。我们的结论更进一步：对于 Multi-Agent 平台（如 AutoGen、CrewAI），公共基础设施应该是平台级能力，而非用户自建的组件。
6.2 治理模型的选择
参考 Bose (2025) 的五种治理模型分类，我们的设计属于规范式（Prescriptive）+ 层级式（Hierarchical）的混合体：
- 规范式：通过 API 协议和事件规范约束 Agent 行为
- 层级式：公共服务层作为"上层建筑"监管 Agent 层
但我们认为，随着 Agent 数量增长，应该逐步引入**经济式（Economic）**元素——例如用 Token 预算机制来调节 Agent 的资源消耗，用声誉系统来激励合规行为。
6.3 Agent 社会的"宪法"
如果认真对待"Agent 社会"这个类比，那么一个自然的问题是：Agent 社会的"宪法"是什么？
我们提出以下基本法则：
- 身份法：每个 Agent 必须有全局唯一的身份标识，由中心化服务分配
- 审计法：每个 Agent 的关键行为必须被独立的第三方记录和审计
- 健康法：每个 Agent 必须定期接受独立的健康检查
- 通信法：Agent 之间的通信必须通过统一的消息总线
- 进化法：Agent 配置的每次变更必须被版本化，支持回滚
这与 SAGA (2025) 提出的"用户对 Agent 生命周期的全面控制"理念一致，也呼应了 Gao & Wu (2026) 的感知-决策-记忆-执行四层治理框架。
6.4 局限性
本文存在以下局限：
- 缺乏大规模实验验证：我们的公共服务架构停留在设计阶段，尚未在 100+ Agent 的场景中验证
- 平台依赖性：我们的实现基于 Multi-Agent 平台，架构设计可能不完全适用于其他 Multi-Agent 框架
- 安全性未深入讨论：我们未充分探讨对抗性场景（如恶意 Agent 伪造心跳、注入虚假日志）
- 去中心化扩展：当前设计是中心化的，在超大规模场景下可能成为瓶颈
7. 结论
本文通过"虾社会"这一隐喻，从实践出发，独立推导出了与学术前沿高度吻合的 Multi-Agent 治理架构。我们的核心发现是：
- 个体能力 ≠ 群体治理：给每只虾装急救包，解决不了公共卫生问题
- 自我管理有天然局限：自己不能审计自己，连代码层面都做不到完美
- 基础设施必须外部化：独立运行、全局视角、第三方性是不可妥协的三个条件
- 规模决定形态：1 只虾不需要医院，1000 只虾必须有；但建设者应该是平台方
这些洞察不仅适用于 AI Agent，也适用于任何分布式自治系统的治理设计。随着 Agent 生态的成熟，我们相信 Agent Infrastructure 将像 HTTPS 之于互联网一样，成为不可或缺的基础层。
参考文献
[1] Chan, A., Wei, K., Huang, S., Rajkumar, N., Perrier, E., Lazar, S., Hadfield, G.K., & Anderljung, M. (2025). Infrastructure for AI Agents. arXiv:2501.10114. Transactions on Machine Learning Research (TMLR).
[2] Gaurav, S., Heikkonen, J., & Chaudhary, J. (2025). Governance-as-a-Service: A Multi-Agent Framework for AI System Compliance and Policy Enforcement. arXiv:2508.18765.
[3] Bose, P. (2025). From Anarchy to Assembly: A Survey of Governance Frameworks for Collaborative LLM Agent Systems. AECTIC 2025 Conference Proceedings. DOI: 10.63282/3050-922X.AECTIC-105.
[4] SAGA (2025). SAGA: A Security Architecture for Governing AI Agentic Systems. arXiv.
[5] Internet of Agents (2025). Internet of Agents: Fundamentals, Applications, and Challenges. arXiv.
[6] Gao, Y. & Wu, S. (2026). A Four-Layer Security Governance Framework for LLM-Based AI Agents. Clausius Press.
[7] de Curtò, J. & de Zarzà, I. (2026). LLM Constitutional Multi-Agent Governance. Accepted at AMSTA 2026, Springer Nature.
[8] Luo, Z. et al. (2026). Auditing Cascading Risks in Multi-Agent Systems via Semantic-Geometric Co-evolution. Accepted at ICLR 2026 Workshop.
[9] Jimenez, C. et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv.
[10] Gur, I. et al. (2024). A Real-World WebAgent with Planning, Long Context Understanding, and Program Synthesis. arXiv.
[11] Zhou, C. et al. (2025). A Unified Architectural Framework for Multi-Agent Systems. arXiv preprint.
本文中的所有代码已在 Multi-Agent 平台上实际运行验证。"虾社会"的概念框架是在与 AI Agent 的对话中逐步推敲形成的——没错，这篇关于 Agent 治理的文章，是和一只 Agent 一起写的。这或许本身就是 Human-Agent Collaboration 的一个有趣案例。
标签：AI Agent · Multi-Agent Systems · Agent Infrastructure · Governance · 系统架构 · 分布式系统
