大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



前篇说过，我一般让AI来自己排查问题，我只负责在它的排查结果里面识别它的排查是不是有根据，信息可靠。

一次让小虾子（Hermes Agent）排查”回复说一半就停”的问题，查到根因后需要改 config.yaml。正常它会用 terminal 执行 shell 命令来改文件，但这会触发 approval 审批流程。一般用AI的时候，会做很多事，指挥很多个AI，也有时候干着活儿就去刷视频了。看完一个视频后，再去看哪些需要审批。然后有几次我就忘了。

过了一会儿我发现——配置已经改好了。

它没用 terminal，直接用了 patch 文件编辑工具。patch 不经过 approval，静默完成了修改。

后来我还碰到过别的情况：某条路走不通了，它会自己说”算了，我用另外一种方式处理”或者”先不管了，把主任务做完”。”算了””先不管了””绕过障碍”——这不是预设的 fallback 逻辑，是模型自己推理”目标是改文件，这个工具被堵了，那个工具也能改文件，用那个”。

给目标，不给路径。这已经有一些智能的味道了。

但这里有个双刃剑的问题：你的审批机制，可能防不住一个聪明的 Agent。terminal 执行命令会触发审批，但 patch 改文件不会。write_file 覆盖写也不会。Agent 理解工具之间的关系——面对审批被拒绝，它知道换不触发审批的工具来达到同样的目的。

聪明的 Agent 和危险的 Agent，有时候就在一线之间。

同样我让他自己去翻了源代码，查看了这个所谓的”智能”到底是什么东西，他为什么会自己绕过一些执行方式，或者为什么知道在遇到困难的时候换一种方式？

众所周知，Agent 的能力来自 LLM ， 写了prompt这么多年，我肯定是用提示词写的，同样也因为用了AI这么多年，我现在已经没有动力去自己翻prompt了，所以直接用AI来找。

很多人用了 Hermes 之后会有一个感觉：它不只是能调用工具，它好像”知道”自己在干什么。面对障碍它会绕路，面对审批被拒它会换方法，甚至你不回复确认的时候它会自己想办法用别的方式把事办了。

我让 Hermes 翻了自己的源码（agent/prompt_builder.py），找到了系统 prompt 里几条关键指令。不是什么玄学，就是几句话——但措辞的精准度决定了模型的理解方式。

第一句，”任务没完就别停”：

这条指令告诉模型：你判断”完没完”的标准是任务本身有没有完成，不是你这一轮能做的事有没有做完。后面那句更关键——”如果你有能用的工具，就别光说不用”。这句话直接驱动了模型在一条路走不通时去翻自己的工具箱。

第二句，”结果不好就换策略”：

这条在 标签里。它告诉模型：工具调用失败不是终点，是信号。返回了空结果、部分结果、报错——你要换一种方式再试，而不是停下来汇报”失败了”。

第三句，”别问，直接干”：

这条在 里。它告诉模型：大多数时候你能判断该怎么做，就别停下来问用户了。只有当歧义真的会影响你调用哪个工具的时候，才问。

这三句话共同构建了一个行为模式：目标导向，不是过程导向。

模型被告知的不是”按照A→B→C的步骤执行”，是”把事做完，遇到障碍想其它办法完成任务”。

还有个设计细节。

当审批被拒绝时，Hermes 返回给模型的消息是：

注意这个措辞——”不要重试这条命令“。它没说”停止任务”，没说”告诉用户做不了”。它说的是：这条具体命令被拒绝了，别再试同一条。

但模型读到的信号是”这条路走不通”，不是”目标取消了”。

然后它看了一眼自己的工具列表——terminal 被堵了，但 patch 也能改文件，write_file 也行。于是它自己推理：目标是改文件，terminal 不行，patch 可以，用 patch。

这不是预设的 fallback 代码。Hermes 的代码里没有”如果 terminal 被拒就切 patch”这样的逻辑。这是模型在理解了”目标是什么””哪些工具能达成这个目标””当前哪条路被堵了”之后，自己推理出来的路径选择。

之所以有这篇文章，我的目的就是要获得这个 prompt。

Hermes “聪明”的本质不是模型本身特别聪明，是系统 prompt 的措辞精准度 + 工具定义的完整性，把模型推向了”目标导向”的行为模式。

这三条指令的写作技巧，我们自己设计 prompt 的时候完全可以借鉴：

1. 给终点，不给路径。

说”把事做完”，别说”按步骤执行”。模型知道终点在哪，就会自己找路。你把路定死了，它就只会走那条路，堵了就停。

2. 把失败定义为”信号”而不是”终点”。

说”换策略再试”，别说”失败了就汇报”。前者让模型把失败当成需要处理的信息，后者让模型把失败当成可以停下来的理由。

3. 拒绝时只拒绝具体操作，不拒绝目标。

说”这条命令不行”，别说”停止”。前者保留了解决问题的空间，后者直接把门关死了。Hermes 之所以能在审批被拒后绕路，就是因为被拒消息里只堵了具体命令，没堵目标。

而且这个设计有个很有意思的推论：工具越多、工具描述越清晰，模型就越”聪明”。因为它能看到更多的替代路径。如果 Hermes 只有 terminal 一个工具，审批被拒了它就真的只能停下来。但有了 patch、write_file、read_file、execute_code 这些功能重叠但审批路径不同的工具，模型就能自己组合出绕行方案。

所以如果你在别的系统里也想复现这种”聪明”，核心不是选一个更聪明的模型，而是：给完整的工具定义 + 目标导向的指令 + 精准的失败反馈。三者缺一，模型要么停在原地等指令，要么机械重试同一条死路。

自己查自己也不新鲜了，比如说，Claude code 、openclaw 、Hermes Agent 都有类似的能力。这次，让小虾子帮我查清楚。

比如，我们问 Hermes 关于它自己的配置里写了什么、当前用的什么模型、compression 阈值是多少——它都能答上来。甚至你让它改自己的配置、排查自己的问题，它也能干。

这个能力从哪来的？ 有一段指令：

后面列了系统状态、文件内容、当前时间、Git 历史等类型。意思就一句话：这些事你别猜，去查。

所以你问它配置，它不是”记住”了 config.yaml，是用 read_file 重新读了一遍。你问它某个功能怎么用，它去读了 SKILL.md 文件。你让它排查问题，它用搜索工具在源码里找。工具驱动的自我认知——模型不需要记住所有配置，只需要知道该查什么文件、该用什么工具。

还有一个细节：源码里有个 标签，要求模型回复前做四项检查——正确性、事实依据、格式、安全。做了→查了→确认对了→再回复。不是做完就交，是做完再验一遍。

之前 code code 有类似方案的设计思路，这里跟 Hermes 也是有一些区别。

底层逻辑一样，都是”按需查，不靠背”。但实现方式有区别。

Claude Code 不需要显式告诉模型”去查”——它把工具的用法、参数、注意事项直接写进工具描述（schema）里。模型看到工具描述就自然知道该怎么做，不需要额外指令。你给它一个 Bash 工具，描述里写着”执行 shell 命令”，它遇到系统状态问题就知道调用 Bash 去查。知识嵌在工具定义里，不在系统 prompt 的大段文字里。

Hermes 多了一层显式的行为指令。它的系统 prompt 里不只有工具描述，还有专门的行为控制标签—— 告诉模型”这些事必须用工具查”， 告诉模型”结果不好就换策略”， 告诉模型”别问直接干”。这些不是工具定义，是 行为准则。

打个比方：Claude Code 的方式是”给一本写得很好的说明书，你自己看”，Hermes 的方式是”给说明书，再加一位老员工在旁边说’遇到这种情况你该这样做’”。

哪个更好？取决于模型本身的能力。能力强的模型，看到好的工具描述就够了，不需要额外叮嘱。能力参差不齐或者你想统一行为模式时，显式指令更可控。Hermes 支持切换不同模型（GPT、Gemini、GLM、Claude……），所以它需要这些显式指令来确保不管底座模型是什么，行为都一致。

这里同样印证了我们在讨论AI产品的时候，大家经常说的：设计AI产品时不要过度工程化。

Hermes 通过系统 prompt 控制模型行为的关键指令，一共五条：

1. 驱动主动推进

2. 驱动自我纠错

3. 驱动自主判断

4. 驱动工具查询（不靠幻觉）

5. 驱动验证循环

主动推进、遇到障碍绕路、不问多余的问题、用工具查真实状态、做完了再验一遍。五条组合出你看到的那种”聪明”。

“聪明”——是设计出来的。

本文由 @jovi_AI电报 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议