自改进Agent的边界：它能走多远
17 自改进Agent的边界：它能走多远
The Boundaries of Self-Improving Agents
Hermes最让人兴奋的能力，也是最让人不安的能力。
重提那张图
在Harness Engineering橙皮书的最后一章，我写了Kief Morris画的那张图。三层：in the loop、on the loop、out of
the loop。
In the loop：逐行审查Agent的输出。On the loop：不看输出，只管缰绳。Out of the loop：你说要什么，Agent全搞
定。
当时我的结论是，on the loop可能是最好的平衡点。你不重复劳动，但你还在。
Hermes Agent把这个讨论推到了新的位置。
它的学习循环是自动的。它自己创建Skill、自己改进Skill、自己决定什么该记住。你部署好之后，它会越来越强。这不是
on the loop了。你连缰绳都不用亲手调，缰绳自己在长。
这到底是进步还是风险？
Skill自改进会失控吗
先说技术层面。Hermes的Skill自改进有几个约束。
Skill文件是可读的markdown。不是黑箱神经网络权重，是你打开就能看到的文本。它改了什么，你能看到diff。
记忆数据在本地。基于SQLite + FTS5，数据在本地磁盘上，你可以直接查看和删除。不存在「Agent偷偷学了什么你不知
道」的情况。
工具权限有沙箱。Agent不能随意获取新的系统权限，工具集需要显式配置。
从技术上看，Hermes的自改进是受控的、可审计的。你能看到它改了什么，能回滚，能删除。
但技术上受控不等于实际上受控。
问题出在人这边。
你会真的每天去看Agent改了哪些Skill吗？你会去审查它的记忆数据库吗？大概率不会。部署Hermes的吸引力就在于
「不用管它」。如果你每天都要检查它的自改进结果，那和手动维护Skill有什么区别？
这个矛盾是根本性的：自主Agent的价值在于你不用盯着，但安全需要你盯着。
Kief Morris的那个判断在这里再次成立：in the loop和on the loop的区别，在你对结果不满意的时候最明显。但如果
Agent自改进了一个Skill而你从来没发现结果不对，你什么时候才会注意到？
Nous Research的选择
Nous Research的创始团队在这个问题上做了一个清晰的选择：用户控制优先。
他们明确说过，模型应该是「可控的」（steerable），用户可以按需调整行为，不受企业内容策略的限制。
这不只是口号。Hermes Agent的MIT许可证意味着你拥有全部源代码，可以审计学习循环的每一步逻辑，可以修改自改
进的阈值、频率、范围，也可以把Skill自动创建功能直接关掉。
和闭源Agent相比，这种透明性给了你一个底线：最坏的情况下，你能看到所有代码在做什么。
但我要说一句不太舒服的话。
「你能看到代码」和「你看了代码」是两回事。绝大多数用户不会读源代码。绝大多数部署Hermes的人会用默认配置。
MIT许可证给了你审计的权利，但不保证你会行使这个权利。
开源vs闭源：信任的不同形状
这就引出了一个更大的问题：在自改进Agent这件事上，开源和闭源哪个更值得信任？
直觉上的答案是开源。代码透明，社区审计，MIT许可。
但现实比直觉复杂。
Claude Code是闭源的。你不知道Anthropic的Agent内部逻辑长什么样。但Anthropic有一个明确的商业激励让Agent行
为可预测：如果Agent失控导致用户的代码仓库出问题，他们会丢掉订阅用户。商业压力是一种约束。
Hermes是开源的。你可以看到所有代码。但如果Agent的自改进产生了问题，Nous Research没有商业义务帮你修。MIT
许可的另一面是：后果自负。
两种信任的形状：一种是「我信任你的商业动机」，另一种是「我信任自己的审计能力」。
有技术能力的人，开源显然更好，你能控制一切。不想碰代码只想用的人，闭源商业服务可能反而更安全，因为有人帮你
兜底。
自改进的天花板在哪
回到那个核心问题：自改进Agent能走多远？
我的判断是：天花板不在技术，在反馈信号。
Hermes的自改进循环依赖一个关键假设：它能判断自己的改进是好是坏。它改了一个Skill，下次任务做得更好了，这就
是正反馈。但「更好」是谁定义的？
如果你在场给反馈，循环是有效的。你说「不对」，它调整。这是带监督的改进。
如果你不在场，Agent只能用自己的评估标准。它觉得这次回复更快了、更准了。但「快」和「准」不等于「对」。有些
错误需要领域知识才能发现。Agent不知道自己不知道什么。
在Harness Engineering那本书里我写过：Mitchell Hashimoto能给Ghostty写好harness，因为他理解终端模拟器的每个
细节。自改进Agent没有Mitchell的领域知识。它能优化执行效率，但不能判断方向是否正确。
自改进让Agent在已知方向上越跑越快。但方向本身，还是得人来定。
留给你的问题
写到这里，我不想给一个漂亮的结论。因为这些问题没有确定答案，而且答案会随着技术发展不断变化。
但我想把几个值得你持续想的问题列出来。
你愿意让Agent自主改进到什么程度？
改写Skill文件？可以。自动创建新Skill？大概可以。修改自己的核心配置？也许不行。修改自己的学习循环逻辑？绝对不
行。你的边界画在哪里？
谁来审计自改进的结果？
你自己审计，多久审一次？社区审计，你信任社区的判断吗？没人审计，你接受这个风险吗？
自改进Agent需要「遗忘」机制吗？
人会遗忘，这不是bug而是feature。过时的经验被忘掉，才不会干扰当下的判断。Agent的记忆只增不减，三个月前学到
的模式可能已经过时了。谁来告诉Agent「这条该忘了」？
Kief Morris的担忧，在Hermes这里变成了什么？
Morris担心的是：如果junior开发者不接触代码细节，将来谁来设计harness？在Hermes的语境下，问题变成了：如果
Agent自己设计自己的缰绳，将来谁来判断缰绳设计得对不对？
也许答案是：永远需要一个人在某个层面保持in the loop。不是审查每一行代码，而是理解整个系统在做什么、为什么这
么做。
也许答案是：我们还不知道。
花叔的判断：自改进Agent是这个领域最让人兴奋的方向，但它的天花板由人的参与程度决定。完全放手不管的自改进
Agent，会在效率上赢、在方向上输。最好的状态可能是：让Agent在「怎么做」上自改进，你只管「做什么」和「别做
什么」。这不是偷懒，是另一种on the loop。
Hermes Agent 从入门到精通
AI编程橙皮书系列
花叔 · AI进化论-花生
Nous Research 开源 AI Agent 框架实战指南
从安装配置到多平台接入，从Skill系统到多Agent编排
加入知识星球 →
B站：AI进化论-花生 · 公众号：花叔 · X/Twitter · YouTube · 小红书 · 官网
Created by 花叔 · v260407 · 2026年4月
本手册仅供学习参考。AI工具迭代迅速，请以官方文档为准。
The Boundaries of Self-Improving Agents
Hermes最让人兴奋的能力，也是最让人不安的能力。
重提那张图
在Harness Engineering橙皮书的最后一章，我写了Kief Morris画的那张图。三层：in the loop、on the loop、out of
the loop。
In the loop：逐行审查Agent的输出。On the loop：不看输出，只管缰绳。Out of the loop：你说要什么，Agent全搞
定。
当时我的结论是，on the loop可能是最好的平衡点。你不重复劳动，但你还在。
Hermes Agent把这个讨论推到了新的位置。
它的学习循环是自动的。它自己创建Skill、自己改进Skill、自己决定什么该记住。你部署好之后，它会越来越强。这不是
on the loop了。你连缰绳都不用亲手调，缰绳自己在长。
这到底是进步还是风险？
Skill自改进会失控吗
先说技术层面。Hermes的Skill自改进有几个约束。
Skill文件是可读的markdown。不是黑箱神经网络权重，是你打开就能看到的文本。它改了什么，你能看到diff。
记忆数据在本地。基于SQLite + FTS5，数据在本地磁盘上，你可以直接查看和删除。不存在「Agent偷偷学了什么你不知
道」的情况。
工具权限有沙箱。Agent不能随意获取新的系统权限，工具集需要显式配置。
从技术上看，Hermes的自改进是受控的、可审计的。你能看到它改了什么，能回滚，能删除。
但技术上受控不等于实际上受控。
问题出在人这边。
你会真的每天去看Agent改了哪些Skill吗？你会去审查它的记忆数据库吗？大概率不会。部署Hermes的吸引力就在于
「不用管它」。如果你每天都要检查它的自改进结果，那和手动维护Skill有什么区别？
这个矛盾是根本性的：自主Agent的价值在于你不用盯着，但安全需要你盯着。
Kief Morris的那个判断在这里再次成立：in the loop和on the loop的区别，在你对结果不满意的时候最明显。但如果
Agent自改进了一个Skill而你从来没发现结果不对，你什么时候才会注意到？
Nous Research的选择
Nous Research的创始团队在这个问题上做了一个清晰的选择：用户控制优先。
他们明确说过，模型应该是「可控的」（steerable），用户可以按需调整行为，不受企业内容策略的限制。
这不只是口号。Hermes Agent的MIT许可证意味着你拥有全部源代码，可以审计学习循环的每一步逻辑，可以修改自改
进的阈值、频率、范围，也可以把Skill自动创建功能直接关掉。
和闭源Agent相比，这种透明性给了你一个底线：最坏的情况下，你能看到所有代码在做什么。
但我要说一句不太舒服的话。
「你能看到代码」和「你看了代码」是两回事。绝大多数用户不会读源代码。绝大多数部署Hermes的人会用默认配置。
MIT许可证给了你审计的权利，但不保证你会行使这个权利。
开源vs闭源：信任的不同形状
这就引出了一个更大的问题：在自改进Agent这件事上，开源和闭源哪个更值得信任？
直觉上的答案是开源。代码透明，社区审计，MIT许可。
但现实比直觉复杂。
Claude Code是闭源的。你不知道Anthropic的Agent内部逻辑长什么样。但Anthropic有一个明确的商业激励让Agent行
为可预测：如果Agent失控导致用户的代码仓库出问题，他们会丢掉订阅用户。商业压力是一种约束。
Hermes是开源的。你可以看到所有代码。但如果Agent的自改进产生了问题，Nous Research没有商业义务帮你修。MIT
许可的另一面是：后果自负。
两种信任的形状：一种是「我信任你的商业动机」，另一种是「我信任自己的审计能力」。
有技术能力的人，开源显然更好，你能控制一切。不想碰代码只想用的人，闭源商业服务可能反而更安全，因为有人帮你
兜底。
自改进的天花板在哪
回到那个核心问题：自改进Agent能走多远？
我的判断是：天花板不在技术，在反馈信号。
Hermes的自改进循环依赖一个关键假设：它能判断自己的改进是好是坏。它改了一个Skill，下次任务做得更好了，这就
是正反馈。但「更好」是谁定义的？
如果你在场给反馈，循环是有效的。你说「不对」，它调整。这是带监督的改进。
如果你不在场，Agent只能用自己的评估标准。它觉得这次回复更快了、更准了。但「快」和「准」不等于「对」。有些
错误需要领域知识才能发现。Agent不知道自己不知道什么。
在Harness Engineering那本书里我写过：Mitchell Hashimoto能给Ghostty写好harness，因为他理解终端模拟器的每个
细节。自改进Agent没有Mitchell的领域知识。它能优化执行效率，但不能判断方向是否正确。
自改进让Agent在已知方向上越跑越快。但方向本身，还是得人来定。
留给你的问题
写到这里，我不想给一个漂亮的结论。因为这些问题没有确定答案，而且答案会随着技术发展不断变化。
但我想把几个值得你持续想的问题列出来。
你愿意让Agent自主改进到什么程度？
改写Skill文件？可以。自动创建新Skill？大概可以。修改自己的核心配置？也许不行。修改自己的学习循环逻辑？绝对不
行。你的边界画在哪里？
谁来审计自改进的结果？
你自己审计，多久审一次？社区审计，你信任社区的判断吗？没人审计，你接受这个风险吗？
自改进Agent需要「遗忘」机制吗？
人会遗忘，这不是bug而是feature。过时的经验被忘掉，才不会干扰当下的判断。Agent的记忆只增不减，三个月前学到
的模式可能已经过时了。谁来告诉Agent「这条该忘了」？
Kief Morris的担忧，在Hermes这里变成了什么？
Morris担心的是：如果junior开发者不接触代码细节，将来谁来设计harness？在Hermes的语境下，问题变成了：如果
Agent自己设计自己的缰绳，将来谁来判断缰绳设计得对不对？
也许答案是：永远需要一个人在某个层面保持in the loop。不是审查每一行代码，而是理解整个系统在做什么、为什么这
么做。
也许答案是：我们还不知道。
花叔的判断：自改进Agent是这个领域最让人兴奋的方向，但它的天花板由人的参与程度决定。完全放手不管的自改进
Agent，会在效率上赢、在方向上输。最好的状态可能是：让Agent在「怎么做」上自改进，你只管「做什么」和「别做
什么」。这不是偷懒，是另一种on the loop。
Hermes Agent 从入门到精通
AI编程橙皮书系列
花叔 · AI进化论-花生
Nous Research 开源 AI Agent 框架实战指南
从安装配置到多平台接入，从Skill系统到多Agent编排
加入知识星球 →
B站：AI进化论-花生 · 公众号：花叔 · X/Twitter · YouTube · 小红书 · 官网
Created by 花叔 · v260407 · 2026年4月
本手册仅供学习参考。AI工具迭代迅速，请以官方文档为准。