上一篇写 Hermes-Agent我们选了一条比较笨但好用的路跟一条消息走一遍。从终端里敲下一句话到 Agent 把最后一个字回到屏幕上中间其实绕了很长一圈消息先被入口收进去变成内部统一的消息会话和上下文被重新组织模型开始一轮轮判断必要时调用工具过程太长时系统还要整理上下文、保住历史并在任务结束后尝试沉淀经验。这条线走完以后Hermes-Agent 的骨架基本就出来了。只不过这种方式更像是在做源码游读主打个走马观花看到什么就说什么、看到一个模块就解释它在这条消息路径里负责什么、看到一个工程细节就顺手拆一下为什么这么做。但问题也出在这走流程容易可以熟悉框架但对于很多设计其实是懵逼的比如Profile 为什么要靠 HERMES_HOME 隔离系统提示词为什么越稳定越靠前记忆为什么会在会话开始时冻结成快照上下文压缩后为什么不覆盖旧会话而是开一个新会话接上父子链…这些细节如果不从全局出发只是走马观花是很难得到完美的答案的。这些东西单独拆开看都不算大甚至有些只是很小的工程取舍可这些东西放在一起就会指向同一个问题Agent 要进入真实工作流需要一套围绕模型的工程约束上一篇跟着一条消息走看到的是模块怎么跑。这篇换个角度这些模块放在一起到底构成了什么为什么这些看起来零散的设计最后会指向同一层系统也就是 Harness再往前看一步未来的软件是不是也要开始为 Agent 设计/整改。Harness 是什么在软件工程里test harness 是一个成熟概念围绕被测代码搭的那层基础设施负责提供输入、捕获输出、管理执行环境让测试可重复、可自动化地跑。被测代码本身不用改harness 在外面把它包住替它处理所有外部依赖和环境问题。而大模型的本质是就是一段文字输入经过推理后输出一段文字。但它自己不会调工具也不会替你管理上下文、处理错误、记住上次做了什么。这些能力需要外面有一层系统来提供。这层东西现在我们叫它 Harness貌似最近又出了个什么环境工程我是真没法跟了…。我更愿意把 Harness 理解成 Agent 的运行时。模型负责提供能力但任务怎么推进、工具怎么用、状态怎么保存都要靠这层系统处理。模型是能力源Harness 决定这股能力能不能走出 demo。现在做 Agent 项目一开始都一个样接一个模型写一段系统提示词加几个工具函数再做一个聊天入口。这个阶段很容易出效果特别是 demo 级别的演示作品任务简单工具少只要模型不是 7B 这种小模型效果都会很不错。但是用户的意图是无限的不会只问一个孤立问题今天让你查资料让你接着昨天的结论改方案改天又补一条新的限制。Agent 做一半发现缺文件权限需要确认跑测试发现环境不对工具返回的错误无法理解。再加上上下文越来越长工具页变多了原来那个模型加函数的结构很快就撑不住了…这时候难点已经从会不会调用工具转成了能不能在一套可控系统里做事。这些问题如果不在系统里处理就会被丢给 prompt。但 prompt 扛不了这么多东西你也可以在 prompt 里写一些要求请谨慎操作确保安全请先检查请保存经验请不要越权......开始的时候也许有用任务越长这些说明文档很快就会被模型忘掉。这些判断不能都靠模型来猜得在模型外面有一层系统把这些东西管起来。这些东西一开始像是零散的工程补丁放在一起看其实就是 Harness 的最初的形状。下面我们沿着 Hermes-Agent 里几个最典型的设计往下看每个点都不大但合起来会看到一个 Agent 从聊天壳往运行时系统长出来的过程。LLM 与系统上一篇从一条消息开始用户输入一句话看起来只是让 LLM 帮忙做事但系统内部其实已经发生了很多转换。入口层先把不同来源的消息统一起来。命令行、Telegram、Slack、飞书、Email这些入口的交互方式完全不一样但进入核心之后都会被收敛成一套内部消息对象。出去的时候也一样模型不需要知道飞书怎么传附件、Discord 怎么带文件它只要吐出统一的媒体协议网关再转回各平台自己的格式。这一步是把平台差异挡在 Agent 核心之外。再往下走是 AI Agent 的主循环它先决定要调用什么工具系统去执行然后把结果拿回来给它它再根据结果判断下一步。就这样反复直到给出最终回答或者预算花光又或者用户主动打断。但 Agent 做事也不是一帆风顺中间会报错也需要模型根据工具的执行结果不断思考和重试。一个真正能工作的 Agent必须允许这种来回调整否则它就只能做短任务任务一复杂要么做不下去要么直接返回一个看起来很像答案的假结果。上一篇我们是把这些都拆开讲了的现在回头看它们其实都在回答同一个问题一个 Agent 要怎么进入真实系统并且长期跑下去真正难的不是让模型回答一句话而是在入口很多、工具很多、上下文越来越长的环境里还能守住权限边界失败以后也能把事情继续往前推。Harness 这个概念就不是为了显得高级才冒出来的它是被模型能力不足 给逼出来的是解决一个个 BUG 逐渐诞生的集合。上下文管理上下文管理是 Harness 里最核心的模块。系统的上下文处理尤其麻烦。模型能不能好好做决策很大程度上就看这一层。用户说过的话、项目里的规则、工具返回的结果、记忆里的偏好都可能影响下一步判断。但模型窗口再大也不是垃圾桶。Hermes-Agent 里那些压缩、缓存、摘要、冻结快照的设计指向的都是同一个问题当前推理到底该带什么什么只要存在数据库里什么值得进入长期记忆。一个短任务 Agent可以不太在意历史。用户问一句模型答一句工具跑一跑完事一个长期运行的 Agent 就不一样。连续对话会积累项目上下文会变工具结果会越堆越多用户还会在半路提出新的需求。这里最怕两件事一是把所有东西都塞进上下文。短期看信息很全长期看又贵又慢而且旧信息会污染新判断、二是把历史直接丢掉。这样成本是省了但用户回头追问时Agent 会失忆。Hermes-Agent 的处理方式是分层。当前推理只保留必要上下文完整历史进 SQLite稳定偏好和项目事实进入记忆真正能复用的流程再沉成 skill。不同类型的数据不该用同一个地方承载模型上下文适合放眼前要用的信息数据库适合放完整记录记忆适合放稳定偏好和项目事实技能适合放可复用的方法和流程把它们混在一起就会很乱。我第一次读到上下文压缩后新开 session、旧 session 作为 parent 保留下来的设计时停了一下。我没想到还可以这样处理上下文也算是给了我一个新的尝试方向。记忆不是把所有聊天记录都塞回系统提示词那样容易失控。Hermes-Agent 把会话中的记忆写入磁盘但当前会话里的系统提示词快照不变下次新会话再加载这个没什么好说一切都是为了成本。这是用一致性换性能的工程权衡。说实话我不确定这个取舍在所有场景下都对。如果用户的偏好在会话中间发生了明确变化Agent 可能要到下一次会话才能反应过来…上下文解决的是当前任务怎么做记忆解决的是下一次能不能少走弯路。工具编排很多人聊工具调用说得挺轻巧好像就是给模型挂几个函数。但真的遇到工具乱调用、不调用又手足无措了…人用软件的时候界面会给你很多暗示按钮放哪儿、什么颜色代表警告、报错以后弹了什么提示人会自己补上下文。但 Agent 不会。它只能看到工具名、参数说明、返回结果如果这些写得不清不楚它就只能靠猜。所以给 Agent 写的工具跟普通 API 不是一回事。API 以前主要是给人用的。人看不懂还能翻文档参数传错了可以看报错跑不通就打断点一边试一边改。哪怕接口设计得别扭一点人也能靠经验兜住。但工具一旦交给 Agent 用情况就不太一样了。Agent 不会像工程师那样慢慢摸索它需要在一次推理里做出判断这个工具到底适不适合当前任务该传什么参数参数错了会不会造成严重后果调用失败之后是重试、换工具还是直接告诉用户做不了......这些东西如果不写清楚Agent 很容易乱用工具不是不会调用而是看起来会用实际用得一塌糊涂。所以给 Agent 设计工具不能只写一份给人看的 API 文档。更像是在给它写一份操作说明什么时候用什么时候别用参数有什么约束失败后怎么处理......写得越清楚Agent 做判断时越不容易跑偏同时API返回的错误信息也会变得特别重要。如果一个工具只返回失败人可以去翻日志Agent 很可能就卡住了更糟的是它还会自己瞎编一个解释接着跑。好的错误信息应该能让它看出来下一步怎么办比如权限不够、路径不存在、网络临时断了还是本来就不该做这个动作。工具一多问题就会更加明显。一开始只有两个工具模型大概还能猜。工具多了以后你得按场景分工具集参数别太啰嗦危险操作要确认别让两个工具干冲突的事。Hermes-Agent 里那些工具注册、并行执行、路径检查说到底就是为了让 Agent 能搞清楚自己到底能干什么、不能干什么。执行控制预算和中断Agent 跑起来以后最怕两件事一是无限循环烧 token二是用户按了 CtrlC 后台还在跑。迭代预算解决第一个问题。主循环有一个硬性预算父 Agent 上限 90 轮子 Agent 50 轮。模型每推理一轮消耗 1 次不管这轮并行调了几个工具。预算耗尽就退出这是硬上限防止模型在错误循环或幻觉里把 token 烧光。级联中断解决第二个问题。父 Agent 每 30 秒给子 Agent 发一次心跳。一旦父被用户中断或者自己挂了心跳断开子 Agent 就会连锁停下。没有这个机制用户按了 CtrlC 之后后台还会有一堆子 Agent 继续烧 token。用户中断的处理也值得说一句。中断发生时不是 raise 抛异常而是 break 出循环先持久化已有结果再返回interruptedTrue。如果前面有工具调用已经追加到消息列表但还没执行系统会补一个伪造的错误 tool result保证消息结构对 API 合法。这个伪造的错误 tool result 非常实用。做过 Agent 的人都知道这个梗用户中断后工具执行也被中断没有记录结果下一轮调用的消息结构就不完整API 直接报错。伪造一个结果回去下次恢复对话就不会被 Provider 拒。工具让 Agent 碰到了真实系统执行控制给了它刹车和油门但跑了以后一定会出错出错以后怎么办错误恢复主循环每一步都可能出问题上下文不够用、API 超时、凭证限流、服务器 500。各种错误长得都不一样HTTP 状态码不同报错信息不同模块来源也不同。Hermes 的做法是按错误分类各走各的恢复路径而不是一个大 try/except。API 调用会失败的原因各种各样认证失败、额度耗尽、限流、上下文超限、模型不存在、网络中断。FailoverReason枚举把这些归了 14 种。每个错误抛出时先过一道分类器再封装成ClassifiedError只带四个布尔恢复标记retryable: bool # 能不能直接重试should_compress: bool # 要不要先压缩上下文再重试should_rotate_credential: bool # 要不要切换到下一个 API Keyshould_fallback: bool # 要不要切到 fallback 模型主循环拿到ClassifiedError之后不自己做字符串匹配只看这四个标记决定下一步。像 rate_limit、insufficient_funds或者 openai 模块抛出的 BadRequestError 这种脏活儿全都集中在分类器里。分类器先把错误映射到恢复动作主循环只负责 dispatch。为什么要分得这么细一个典型的对比是 HTTP 402 和 429。它们表面都是限额类错误但处理方式完全不同429 是临时限流Provider 告诉你请求太快需要歇一下再来退避重试同一个 Key 就能恢复402 是额度耗尽账户上的钱已经扣光了同一个 Key 短期内不会恢复必须立即切到下一个 Key不分清楚的话Agent 会在一个已经没钱的 Key 上反复退避到天荒地老。分类器把这两种错误映射到不同的恢复标记组合主循环看标记就知道该退避还是该换钥匙。对做过后端的人来说这应该不陌生。和微服务里的重试、熔断、降级是同一类问题。只是放在 Agent 场景下错误来源更杂。模型 API、工具执行、文件系统和网络都可能抛出不一样的失败分类器的作用就是在这个大杂烩里理出头绪。错误恢复解决的是出了事怎么继续走。但 Agent 还有一类问题比出错更麻烦它做了不该做的事怎么办权限与安全一提权限其实挺烦的。我们在使用 Claude Code 的时候经常会遇到一个弹窗是否允许它执行某个操作。从体验上说这东西很打断每多一次确认自动化就少一点顺滑感。尤其是做演示的时候一个 Agent 从头跑到尾中间完全不问人看起来当然最厉害。但问题在于Agent 不是只在聊天框里生成文字。它开始影响真实环境了改文件、跑命令、调外部 API、发消息甚至触发一整套业务流程。虽然我们也不想要权限但它确实是真实运行时的一部分并且还是非常重要的一步。回想当年做信息化转型的时候财务的数据无论如何都进不去财务部门的人咬死不松口就是这个道理写文件这件事本身不一定危险。写到 /tmp 目录很多时候可以直接放行但如果要改 .env、配置文件、启动脚本那就不是一回事了。跑命令也是一样。ls、cat、git status 这类读状态的命令通常没必要每次都拦但一旦涉及删除、覆盖、部署、提交变更就必须让人确认。外部 API 更明显。查一条订单信息和取消一笔订单虽然都叫调用接口风险完全不是一个级别。所以权限控制最好绑定到具体动作和上下文而不是只绑定到某个工具名。Agent 真正跑起来以后最麻烦的不是会不会调用工具而是它可以自己做什么什么必须停下来问人。读一个文件可以直接放行删一个目录就不能这么随便发一封邮件、下一个订单、改一段共享记忆这些动作更不能全交给模型自己判断......边界说不清Agent 看起来是在自主执行实际上就是靠默认策略硬跑。跑对了叫智能跑错了就是事故。Hermes-Agent 这块当然还谈不上终局方案但它至少已经把边界放进了运行时而不是只停留在提示词里。比如工具集可以启停危险命令要审批子 Agent 不能无限套娃式地继续委托也不能直接写共享记忆、不能随便对外发消息父 Agent 一旦被中断下面的子 Agent 也要跟着停工具调用被打断了系统也要补一个结果回去避免下一轮消息结构直接乱掉......这些设计看起来很细其实解决的是同一个问题Agent 可以有自主性但不能乱跑乱撞。权限解决的是 Agent 能不能做、做到哪里。可任务做完以后还有另一个运行时问题这次执行带来的经验能不能留给下一次。经验沉淀Agent 做完一次任务以后到底留下了什么聊天记录工具调用日志模型请求日志…如果答案只是聊天记录那这套系统其实没有变聪明下次遇到类似问题它还得重新摸索最多是用户自己去翻历史把上次的经验再喂给它。我们和 AI 交互时经常这么做把有用的提示词、排查步骤、项目习惯记到自己的小本本里下次再复制进去。Hermes-Agent 有一个很有意思的主张经验保存到技能越用越聪明。技能不是神奇能力说简单点就是一份可复用的操作笔记。某个项目怎么跑测试某类问题以前怎么排查某个工具有什么坑这些东西如果只散落在对话里Agent 下次未必找得到。沉成 skill 以后它就从一次性的过程变成了系统可以再次调用的经验。核心动作就是任务结束后另起一个安静的 mini Agent 回看这段对话判断有没有值得保存的方法。这个动作放在用户收到回复之后不抢主任务的注意力也不增加用户等待时间。这一点其实很像团队里的经验沉淀。一个团队不会因为项目做完了就自然变强。真正让团队变强的通常是项目之后留下来的东西复盘结论、更新过的文档、补齐的工具、调整后的流程。没有这些沉淀忙完一轮下一次还是从头摸索。Agent 也一样。一次任务跑完过程再精彩如果执行轨迹没有留下来下次遇到类似问题它还是要重新试一遍。这个时候所谓自主执行其实更像一次性劳动。Hermes 用 Skills 机制完成了这一切但我不太愿意把这叫自进化这个词太大也太容易把事情讲玄。更准确地说它是在做持续积累Agent 不只是把眼前这件事做完还要尽量把有用的经验带到下一轮。到这里Harness 的边界就从 Agent 自身往外扩了一步。Agent 想沉淀经验前提是它能读懂自己操作过的系统而软件想被 Agent 稳定使用也得开始把动作、状态和失败原因讲清楚。软件要适应 Agent如果 Harness 继续成熟软件本身也会被反向改造。过去做软件默认使用者是人。界面上的按钮、菜单和流程都是围绕人的理解方式组织的。人能看懂上下文也能靠经验判断什么时候该点、出了错该怎么查、什么操作会影响线上数据。这个前提不会消失。人仍然要看界面、做判断、承担责任UI 也仍然重要。但 Agent 进入工作流以后软件会多出另一种使用者。Agent 可以看页面、点按钮甚至模拟浏览器操作但这不是最稳定的方式。页面里有太多默认语境一个提交按钮人知道它大概意味着什么一句操作失败人会去查日志、问同事、回想业务规则。Agent 没有这些经验只能猜。所以未来的软件能力不能全藏在 UI 里也不能只停留在传统 API 层。很多系统早就有 API但那些 API 主要是给工程师集成用的。字段名可能只有内部人懂错误信息可能只是方便查日志权限规则也可能散在业务代码里。工程师可以一边调试一边补理解Agent 不行。它要稳定调用一个能力需要系统把运行时语义说清楚。比如提交审批这个动作光有接口还不够。Agent 需要知道当前状态能不能提交提交前要补齐什么字段失败后是缺字段、没权限还是流程状态不允许。它还需要知道这个动作会造成什么后果是否需要先停下来等人确认。能把这些东西表达出来才算是在为 Agent 设计。这并不是说以后软件都会变成聊天框。界面不会消失人也不会退出流程。变化在于软件除了给人看、给人点还要把一部分能力整理成 Agent 能理解、能判断、能安全调用的形式。这个变化会先影响内部系统。以前做内部系统一个功能能点到、能看懂、别太反人类基本就能交差。Agent 进来以后标准会多一层这个功能能不能被它接住条件有没有写清楚失败信息够不够它判断下一步而不是只返回一句操作失败。一旦这个标准成立软件设计的重心就会慢慢偏移。功能入口不再只是页面上的按钮也可能是 Agent 编排任务时的一块积木。流程也不一定非要按页面一步步走。只要权限、状态、前置条件和风险边界足够清楚Agent 就可以在边界内重新组合动作。日志也会变得更重要。它不只是给工程师排查问题还会成为 Agent 理解执行过程的依据刚才发生了什么哪一步失败了失败之后还能不能继续。所以不是 UI 消失了。更准确地说是软件多了一层新的读者以前主要写给人看现在还要让 Agent 看得懂、接得住、用得稳。结语在我们真正做 Agent 开发的时候会发现基于半年前的模型和半年后的模型对于工程能力的要求是不一样的。只不过模型当然重要没有模型能力Harness 只是一个空架子。但长期看只讨论模型很容易把问题讲窄。模型会变能力边界也会变。今天是某个模型工具调用更稳明天可能是另一个模型上下文更长后天又冒出一个新的推理模型。系统如果把自己绑死在某一个模型上迟早会被动。更值得投入的是模型外面那层东西。上下文不是越多越好工具也不是挂上去就完事。权限要落到具体动作上失败以后要能接着走历史和经验也得能被下一次任务找回来。这些没有模型发布会那么热闹但它们决定 Agent 能不能在真实工作里长期跑。Hermes-Agent 给我的启发就在这里。它当然不是标准答案也不是未来所有 Agent 系统都该照着它长。但它像一个很好的早期切片你能看到一个 Agent 从聊天壳往运行时系统长出来的过程。上一篇文章我们跟着一条消息走了一遍看到的是 Hermes-Agent 怎么把一次对话跑完这一篇看的是另一层如果把这条链路放远一点它背后正在成形的是一套 Harness。它关心的不是某一次回答够不够聪明而是模型能力能不能在真实工作流里稳定、安全、可持续地运行。再往前看一步Harness 还会反过来影响软件本身。未来的软件不会只被人使用Agent 也会使用它。系统不能只给 Agent 一个接口地址还得把动作的语义说清楚什么时候能用当前处在什么状态越界了怎么办失败之后还能不能补救什么地方必须停下来等人确认。这些听起来都是工程细节但新一代软件的入口很可能就是从这些不起眼的地方长出来的。我现在对 Agent 的判断也更保守了一点。一个 Demo 能跑通说明不了太多。真正值得看的是它连续跑十几轮之后还稳不稳出错的时候会不会停下来而不是继续硬冲任务做完以后有没有把过程里的经验留下来。还有一个更容易被忽略的问题它接入的那个软件本身有没有给 Agent 留出清楚的动作层。如果这些问题回答不上来再强的模型也只能撑一阵。如果回答得上来Agent 才可能真的从聊天框走出来成为软件系统里一层新的执行能力。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】