本文翻译自：Hermes Agent Changed How I Think About Execution Boundaries，作者 Hema Priya Kanagala。
TL;DR
传统自动化假设软件执行是可预测的。
Agent 系统的行为则不同。它们需要运行时边界、验证循环和持续引导。
在深入理解 Hermes Agent 的架构后，我意识到未来的自动化可能不在于脚本化的工作流，而在于为自主系统设计安全的运行环境，使其能够可靠地运作。
预计阅读时间：约 8 分钟
目录
- 传统自动化假设确定性执行
- Agent 系统的行为截然不同
- 用运行时压力取代静态超时
- 为什么执行边界至关重要
- 安全的范式转移：从权限到操作约束
- 为什么验证循环很重要
- 上下文正在演变为事件系统
- 异步 Agent 工作流的兴起
- 本地模型改变了基础设施假设
- 这对开发者意味着什么
- 最后的话
- 参考资料
传统自动化假设确定性执行
大多数软件系统假设执行是可预测的。
一个脚本运行。
一个工作流重试。
一个异常使进程崩溃。
一个超时终止失控的执行。
即便是大型分布式系统，仍然在确定性边界内运行。工程师定义精确的执行路径，由基础设施来强制执行。
然而，一旦自主 Agent 进入视野，这种心智模型就开始崩塌。
在花时间深入探索 Hermes Agent 之后，我意识到了一件重要的事情：
Agent 系统不仅仅是「更智能的自动化」。
它们的行为更不像固定的工作流，而更像在预定义限制内动态做出决策的系统。
这改变了开发者需要设计的东西。
Agent 系统的行为截然不同
传统自动化遵循预定义的步骤。
Agent 系统则完全不同。
开发者不再手动编写每一个动作，而是给予系统：
- 工具
- 指令
- 边界
- 目标
然后 Agent 自行决定如何推进任务。
这种区别至关重要。
开发者不再编写每一个动作，而是定义：
- Agent 可以访问哪些工具
- 它可以运行多长时间
- 它不能跨越什么边界
- 失败如何被验证
- 运行时行为如何被约束
在这个语境下，「执行边界」指的是塑造自主系统运行时行为的操作限制和保障措施。
系统不再直接控制每个步骤。
它正在塑造推理发生的环境。
Hermes Agent 以一种超乎我预期的方式，清晰地展示了这种转变。
最明显的例子之一，就是它如何处理长时间运行的任务。
用运行时压力取代静态超时
传统系统通常依赖硬性超时。
如果一个进程超过限制，它就会被终止。
Hermes 对此采取了不同的方式。
它使用一个**迭代预算（Iteration Budget）**系统，在 Agent 接近执行限制时持续施加运行时压力。
Hermes 不是立即终止执行，而是向工具响应中注入隐藏警告：
{
"_budget_warning": "[BUDGET WARNING: 81/90. Only 9 left. Respond NOW.]"
}初看之下，这像是一个小小的实现细节。
但从架构层面看，它代表了一种完全不同的哲学。
系统不是简单地强制执行超时。
它正在主动引导推理过程走向优雅完成。
这改变了开发者的角色。
开发者不再完全依赖硬性终止，而是越来越多地设计能够在执行过程中引导自主行为走向安全结果的系统。
为什么执行边界至关重要
在 Hermes Agent 的架构中，有一个理念反复出现：
系统假设推理引擎本质上是不可预测的。
这个假设改变了一切。
传统软件信任执行，因为逻辑是由开发者直接编写的。
Agent 系统动态生成执行路径。
这引入了一个新的挑战：
你如何安全地授予自主权，同时又不允许不受限制的执行？
Hermes 通过分层的执行边界来解决这个问题。
一个例子是它的硬性黑名单（Hardline Blocklist）。
即使用户启用了激进的自主执行模式，Hermes 仍然会阻止灾难性操作，例如：
- 破坏性文件系统擦除
- 块设备写入
- Fork 炸弹
- 危险的 Shell 模式
这在推理层之下发生。
Agent 可以自由推理，但执行仍然在确定性约束内进行。
这种分离非常重要。
系统不完全依赖语义意图或提示指令来保证安全。
相反，它在 Agent 之下建立了物理操作边界。
我认为这是现代自动化系统中最重要的架构转变之一。
安全的范式转移：从权限到操作约束
传统安全模型通常是基于权限的。
你授予：
- API 作用域
- 数据库权限
- 访问角色
这在软件行为可预测时效果良好。
Agent 系统使这一点变得复杂，因为生成的代码和执行路径并非完全预先可知。
这在多个方面增加了潜在攻击面：
- 工具滥用
- 提示注入攻击
- 不安全的 Shell 执行
- 权限过大的集成
- 意外的破坏性操作
Hermes 通过多个层面来处理这个问题。
一个层面在执行前评估语义意图。
另一个层面强制执行不可绕过的确定性安全规则。
模型上下文协议（MCP）也引入了另一个重要考量。
MCP 允许 Agent 通过共享协议接口动态地与外部工具和服务交互。
这种灵活性非常强大，但同时也意味着开发者必须仔细考虑工具的暴露范围。
Hermes 鼓励通过允许列表和排除策略进行严格的工具过滤。
开发者不是暴露一切，而是定义最小可行的操作表面积。
我认为，随着自主系统能力不断增强，这种思维方式将变得越来越重要。
目标不是限制有用的自动化。
目标是创建自主性能够在明确定义的边界内安全运行的环境。
为什么验证循环很重要
传统软件与 Agent 系统之间最大的区别之一是，推理系统可能自信地描述从未实际完成的工作。
Hermes 明确防范了这一点。
它包含一个文件变更验证器，用于审计文件操作是否真正成功。
如果某个操作静默失败，Hermes 会将纠正性反馈注入回对话状态。
换句话说，系统独立检查工作是否真正发生，而不是信任 Agent 的摘要。
在确定性软件中，成功执行通常被认为是理所当然的，除非出现异常。
在 Agent 系统中，「没有异常」已经不够了。
系统越来越需要独立的验证层来确认：
- 文件系统状态
- 命令执行结果
- 基础设施变更
- 部署结果
如果没有验证循环，幻觉式的成功可能累积成真正的运营问题。
这并不意味着自主系统不安全。
它只是意味着它们需要一种不同风格的工程纪律。
上下文正在演变为事件系统
Hermes Agent 内部最有趣的实现细节之一，是它如何处理上下文加载。
许多系统会在启动时积极加载大量信息。
其假设很简单：
更多上下文等于更好的推理。
但大型上下文窗口引入了真正的权衡：
- 更高的延迟
- 更大的成本
- 更低的缓存效率
- 更慢的迭代周期
Hermes 通过一种称为**渐进式披露（Progressive Disclosure）**的方式采取了不同的方法。
Hermes 不是在启动时立即加载每个项目指令，而是等到 Agent 实际导航到相关目录时。
只有在那时，它才注入关联的上下文。
例如，如果 Agent 进入一个后端目录，Hermes 可以只加载与项目那部分相关的指令，而不是在启动时加载整个代码库。
在实践中，文件系统导航成为了上下文激活的事件触发器。
这听起来可能很微妙，但其含义非常深远。
系统提示实际上成为一个必须保持稳定的计算缓存。
未来的瓶颈可能不是上下文大小本身。
而可能是持续变更上下文的成本。
这改变了开发者对 AI 系统中内存、状态管理和长时间执行的思考方式。
异步 Agent 工作流的兴起
大多数人仍然通过同步聊天界面对与 AI 系统交互。
你问一个问题。
模型立即响应。
Hermes 通过隔离的后台执行会话支持一种不同的模式，这些会话可以独立继续运行并稍后返回结果。
这在相当程度上改变了交互模型。
某些任务天然适合更长时间的执行：
- 大型代码库变更
- 基础设施审计
- 多步骤研究任务
- 部署准备
- 复杂编排工作流
在这些情况下，持续在实时聊天界面中等待开始变得局限。
Hermes 通过允许执行在后台继续，同时单独保存 Agent 的工作状态来解决这一问题。
我发现有趣的是，这也改变了调试的方式。
当执行发生在临时云环境中时，一旦环境消失，理解实际发生了什么就变得更加困难。
Hermes 通过在拆除环境之前将修改过的产物同步回主机系统来处理这个问题。
这创建了一个持久化的执行轨迹，开发者可以事后检查。
调试过程不再是阅读单个堆栈跟踪，而是更多地重建 Agent 遵循的更广泛执行路径。
本地模型改变了基础设施假设
Hermes Agent 内部一个微妙但重要的细节是，它对待本地模型与云 API 的方式截然不同。
大多数开发者假设 API 响应很快。
本地模型打破了这一假设。
大型本地推理工作负载可能在生成响应之前花费大量时间处理上下文。
Hermes 通过动态调整网络行为来适应这一点：
- 延长 Socket 超时
- 放宽流式假设
- 容忍长时间的预填充阶段
这在操作层面听起来可能很细微，但它揭示了更深层次的东西：
AI 基础设施越来越依赖计算硬件的物理现实。
随着自托管模型变得更加普遍，开发者可能需要重新思考：
- 超时假设
- 同步工作流
- 网络期望
- 基础设施韧性
本地 AI 系统的「物理特性」成为应用架构的一部分。
这对开发者意味着什么
我并不认为 Agent 系统降低了开发者的重要性。
如果说有什么变化，那就是它增加了深思熟虑的工程实践的重要性。
角色只是演变了。
开发者仍然负责：
- 定义边界
- 设计基础设施
- 约束执行
- 验证结果
- 构建可靠的系统
- 保护操作表面
改变的是抽象层级。
开发者不再手动编写每个确定性工作流，而是越来越多地塑造自主推理安全运行的环境。
这需要：
- 系统思维
- 运营纪律
- 安全意识
- 基础设施设计
- 运行时治理
这就是 Hermes Agent 如此值得探索的原因。
它不只是自动化任务。
它暴露了一旦推理系统成为软件基础设施中的主动参与者，随之而来的更深层次的架构问题。
最后的话
传统自动化假设执行是确定性的。
Agent 系统不这么认为。
这种差异改变了软件系统的设计方式。
在深入探索 Hermes Agent 之后，我得出了一个核心认识：
未来的自动化可能不再是定义精确的执行步骤。
它可能更多地是设计自主系统能够可靠运行的安全环境。
而这使得软件工程变得更加重要。
因为自主系统仍然需要精心设计的基础设施、操作保障、验证层和深思熟虑的人类监督，才能在现实世界中可靠地工作。
所以，我很好奇：
有什么事情是你绝对不会让自主 Agent 完全独立去做的？
参考资料
在研究和撰写本文的过程中，以下 Hermes Agent 文档对理解系统架构、执行模型、安全模式和运行时行为特别有帮助：
在形成本文讨论的更广泛观点时，我还探索了额外的 Hermes Agent 文档和快速链接资源：
其中包括架构文档、内存系统、技能、工具、MCP 使用模式、学习路径、故障排除资源和最佳实践。