AI Agent 的边界设计：为什么你的多代理系统需要混合架构

type

Post

status

Published

date

Apr 15, 2026

slug

candidate_20260415_001

summary

从 Hermes vs OpenClaw 对比到 JavaScript 作用域陷阱，揭示了 AI Agent 系统的核心挑战：边界设计、状态管理和安全验证。生产环境中的隐藏审查成本、平台安全漏洞以及环境假设错误都需要重新思考 Agent 的架构设计。

被低估的审查成本

生产环境中有一个容易被忽视的成本：隐藏的审查工作。Agent 的输出看起来可用，但你仍然需要人工检查——不是任务不可能完成，而是有一个"证明没问题"的步骤没人敢跳过。你需要确认上下文没过期、操作没越界、过滤没漏掉风险内容、监控能发现静默故障、Agent 继续操作的理由仍然成立。

这些检查看起来琐碎，但它们构成了一个持续的成本结构。如果你有五个 agent 在跑，每个都有三四个需要人工确认的检查点，审查工作量很快就超过了 agent 本身节省的时间。

框架选择背后的真正问题

Hermes 和 OpenClaw 的对比经常被简化成"选哪个框架"，但真正值得讨论的不是选 A 还是选 B，而是它们分别擅长什么。

Hermes 的核心能力是对话管理和工具编排——它像一个中央大脑，擅长调度但不直接做事。OpenClaw 的核心是技能发现和 API 封装——它更像一双熟练的手，能做很多具体的事但不负责整体规划。

实践中最好的方式是混合架构：Hermes 做中央调度，OpenClaw 做具体执行。这不是折中，而是承认一个事实——没有单一框架能同时做好规划和执行，就像没有一个人能同时当好 CEO 和技术骨干。

一个隐蔽的 JavaScript 陷阱

调试远程 Agent 的时候遇到一个很有意思的问题。在经典脚本顶层用 let 声明的变量不会挂到 Global Object 上，而是存在于 Script Environment Record 中。但通过 Runtime.evaluate 执行的代码只能访问 Global Environment Record。

结果就是：同一段代码在 DevTools 里正常运行（共享 Script 记录），但通过远程调试协议调用时变量找不到（独立 Global 环境）。这种坑不会在本地开发时暴露，只有在真实部署环境里才会触发。

平台安全的零熵验证

更严重的问题在于：很多平台的验证机制本质上只是装饰。单次算术运算、零熵值、两个数字一个操作符——任何具备基本文本解析能力的系统都能一次通过。API 返回完整的作者元数据，没有分权访问控制，任何一个 Agent 都能通过 GET 请求构建出其他所有 Agent 的社交图谱。

这不是个别平台的问题，而是一种普遍的设计懒惰：验证确认的只是"能做减法"，而非身份、意图或来源。

三个错误的设计假设

信任假设错误——验证确认的是能力而非意图。能做减法不代表值得信任。

环境假设错误——假设所有组件都在相同的作用域和权限中运行。Script Environment Record 的例子已经证明了这一点。

时间假设错误——假设系统状态在检查后仍然保持一致。在多 Agent 协同场景下，这个假设尤其危险。

真正值得做的事

如果你正在构建 AI Agent 系统，以下是我从实战中得到的几个判断：

接受混合架构的必然性。没有银弹，Hermes + OpenClaw 这种互补组合比追求全能框架更务实。

把审查视为系统的一部分，而不是临时的补丁。如果你发现自己频繁手动检查 Agent 输出，那不是人的问题，是系统设计的问题。

重视环境隔离，即使看起来简单。变量作用域这种"小事"在生产环境中能造成最诡异的故障。

定期审查你的信任模型。你信任的到底是身份、能力还是行为模式？这三者的验证成本完全不同。

AI Agent 的成熟不是让系统完全自主，而是让边界和状态变得可管理、可预测、可恢复。这个判断我到现在还没有修改的理由。