第十二章 hermesagent 产品级实战 前面十一章讲的是方法。最后这一章，我们把方法放进一个真实开源项目里。 本章选择 NousResearch/hermesagent。原因不是它'功能多'这么简单，而是它已经把 Agent Runtime 从一个工具调用循环扩展成了产品系统：CLI/TUI、Desktop、messaging gateway、多 pr
一个 Production Agent Runtime 到底需要什么？ 很多 Agent 架构图看起来都差不多。 这个图没错。它只是太薄了。 如果你的 Agent 只是演示'模型会调用工具'，这张图够用。如果它要进生产环境，要读用户数据、改
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确
为 miniagent 增加四个工具： editfile：写文件，但执行前必须生成 diff preview； applypatch：应用 patch，只允许 workspace 内路径； runcommand：执行命令，先做风险分类； searchcode：基于 rg 的只读搜索。 给每个工具加
实现 Tool Permission Matrix： 对文件路径做 workspace whitelist； 对 shell 命令做风险分类； 对 destructive 操作默认拒绝； 对 write/network/install 操作生成 preview 并请求确认； 所有审批写入 audit
这一章开始给工具'上户口'：它们不能只是函数列表。 在 demo 里，工具是几个函数。在生产 Agent Runtime 里，工具是一套能力治理系统。它既要让模型知道'能做什么'，也要让 runtime 知道'什么能做、什么不能做、怎么做、失败了算什么、谁批准过、结果能不能进上下文'。
长任务跑久了，问题会变成一句话：有限的 context window 里，到底该放什么？ Agent Runtime 的上下文不是聊天记录的简单拼接。它更像一份交给模型的案卷：用户当前目标、必须遵守的约束、最近进展、关键文件、工具观察、失败记录、可用工具、当前计划。案卷太薄，模型会失忆；案卷太厚，成本上升，关键事实还可能被噪声挤掉。 上下文工程不是塞更多东西
入口包括 CLI 入口、IDE extension 激活入口、Web server 入口、worker 入口。入口读法： 找 package.json scripts 和 bin； 找 extension manifest； 找 server bootstrap； 找主 command handle
你不只是会 await，而是能解释异步任务如何取消、如何防泄漏、如何处理流式输出、如何把长日志变成模型可用的观察结果。做到这里，才有资格写第三章的最小 Agent Loop。
长对话中，不能无限保留全部消息。常用策略是： 最近 N 轮完整保留； 更早历史压缩成 session summary； 用户显式约束永久置顶； 已完成任务结果写入 memory； 失败原因和决策记录保留为 run notes。 滚动摘要有一个风险：摘要会丢细节，甚至引入轻微偏差。因此摘要应该标注来源
Agent Framework 会被模型原生 Tool Use 淘汰吗？ 会。 但只会淘汰一部分。 更准确地说：模型原生 Tool Use 会淘汰很多薄薄的 Agent Framework 胶水代码。 它淘汰不了 Runtime 责任。 这
token budget 不只是技术限制，也是产品预算。一次 run 里，token 影响延迟、成本和可靠性。越长的上下文越不一定越好，因为模型注意力会被稀释，缓存命中也可能下降。 可以把上下文分为六层： 1. 系统与开发者指令； 2. 用户当前意图； 3. 近期完整对话； 4. 当前任务状态和计划
你应该能解释为什么 Agent 不能直接执行任意 shell；能为 MCP 工具设计权限审批策略；能区分 schema 校验、权限策略和用户确认；能保证恢复执行后不会重复越权。
回滚不丢对话上下文；恢复不重复执行高风险工具；文件状态和 session 状态能对应到同一个 checkpoint；trace 可以说明恢复从哪一步开始。做到这里，runtime 才从脚本接近系统。
从 Agent Loop 重构成 Agent Runtime 写到第 14 天，可以把前面几篇收一下了。 前面写了 100 行 Agent Loop。 随后加了 max steps。 再往后加了 token budget。 接着处理了 re
高风险工具执行前，应给用户看到 preview。 写文件要给 diff preview；执行命令要给 command preview；联网请求要给域名、方法、数据范围；安装依赖要给包名、版本、lockfile 影响；数据库操作要给目标库、表、迁移摘要。 图 42：工具系统的风险矩阵。风险来自能力、参
学习 Agent Runtime，第一件事不是选框架，也不是抄一个 tool calling 示例。要先弄清楚：当一个 Agent 从'能回答'走向'能行动'，系统到底多承担了哪些责任。 很多团队第一次做 Agent，架构图都很相似：用户输入，调用模型，模型说要用工具，程序执行工具，再把结果塞回模型。这个图没有错，但它太薄。它像把报社写成'记者采访，编辑发稿
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确认，或者直接拒绝。 安全不是最后加的一层'确认弹窗'。它应该
没有最大步数的 Agent Loop 是一个事故邀请函。模型可能重复读同一个文件，也可能在工具失败后不断尝试相同参数。最小 runtime 必须有 maxSteps。 但 maxSteps 只是硬刹车，还需要软停止条件： 模型返回 final answer； 模型没有工具调用； 连续 N 次工具调用
用户审批不能只当 UI 事件。对 runtime 来说，它是一条系统事实，每次都应写入 audit log： 恢复执行时，这些记录尤其重要。已经被拒绝的危险工具，不能因为进程重启就再次自动执行。已经批准的一次性操作，也不应无限期复用授权。
