OpenHarness 源码解读:Agent 是怎么跑起来的
昨天下午,我在看一个开源项目,HKUDS出的,叫OpenHarness。
点进去看了眼源码,说实话,我突然觉得悟了!
不是因为它多牛,是因为它把一个我想了很久的问题,说清楚了:Agent这玩意儿,到底怎么跑起来的?
先说个大白话
我做了三年AI,这个问题我一直没完全想明白。
你看,每个框架都说自己有Agent,LangChain有,AutoGen有,OpenClaw也有。
但Agent到底是个啥?
有人说,Agent就是能调工具的LLM。有人说,Agent是有记忆的LLM。有人说,Agent是能自己规划任务的LLM。
都对,又都不对。
OpenHarness的代码让我想明白了一件事。
Agent的本质,就是一个循环。
就这么简单。
循环长啥样
我尽量不用代码讲,用大白话说。
你给模型发个消息,模型回复你。回复里可能带着工具调用,比如「我要读这个文件」。
然后系统执行这个工具,把结果塞回去,再发给模型。
模型看到了结果,可能又说要调另一个工具。再执行,再塞回去。
一直循环,直到模型不再调工具为止。
就这?
我看完源码的第一反应是,我靠,就这么简单?
对,就这么简单。
但简单不代表没用
OpenHarness让我服的地方,不是它发明了什么新东西。
而是它把每个模块该干什么,拆得清清楚楚。
工具调用——这是Tools模块的事,43个工具,文件读写、搜索、Web、MCP,全有。
知识注入——这是Skills模块的事,你要用什么知识,按需加载。
权限控制——这是Permissions模块的事,什么能做什么不能做,提前定好。
生命周期钩子——这是Hooks模块的事,工具执行前后插一脚,想干嘛干嘛。
多智能体协调——这是Coordinator模块的事,怎么派活,怎么收活。
每个模块只干一件事,合起来就是一个完整的Agent。
这就是工程思维!
说到Hooks,这个我得多聊聊
这是我看源码时觉得最骚的设计。
你想想,OpenClaw现在有个问题,每次我想加个安全检查,都得改工具代码。
比如我想记录每次文件删除操作,我得去改file_delete工具。
我想统计API调用成本,我得在每个工具里加计数逻辑。
很烦。
OpenHarness用Hooks解决了这个问题。
pre_tool_use——工具执行前,插一脚。
post_tool_use——工具执行后,插一脚。
你想干嘛,写个Hook就行,不用动任何工具代码。
我举个例子。
你想拦截所有「rm -rf /」命令,之前你得去改bash工具,加判断。
现在,你在pre_tool_use里写个正则,匹配到了直接返回blocked=True,工具根本不会执行。
安全检查、日志记录、成本统计、审计追踪,全都能抽成插件。
这就是我说的,扩展性质的飞跃。
还有个东西让我意外
权限控制这块。
OpenHarness设计了三种模式。
Default——写操作前问你一声,适合日常开发。
Auto——全放行,适合沙箱环境。
Plan Mode——阻止所有写操作,适合大型重构时先审查。
这还没完。
它还有个叫path_rules的东西,用配置文件规定哪些路径不能碰。
{ "path_rules": [ {"pattern": "/etc/*", "allow": false}, {"pattern": "~/.ssh/*", "allow": false} ]}看到这我脑子里灯泡就亮了。
这不就是我们在AGENTS.md里写的红线黄线规则吗?
区别是,我们写在文档里,OpenHarness写在配置文件里。
文档靠「记得」,配置靠「自动检查」。
哪个靠谱?不用我说吧。
有什么可以借鉴的?
看完源码,我脑子里一直在想一个问题。
我能不能把这些东西引入OpenClaw?
能。
第一,Hooks。
pre_tool_use和post_tool_use两个事件,就能让整个插件生态活起来。
不改任何工具代码,想加什么功能加什么功能。
第二,权限精细化。
path_rules和denied_commands,用配置文件固化红线黄线规则。
不再依赖「记得」,而是依赖「配置」。
这两件事,让openclaw自己解决,一会就能搞定。
最后说一句
OpenHarness不是竞争对手。
它的定位是「研究者的轻量harness」,OpenClaw是生产级平台。
它是参考答案,不是标准答案。
但有些东西,是真的值得学。
比如Hooks的设计,比如权限的精细化,比如模块拆分的清晰度。
看完代码我脑子里一直回荡着一句话:模型决定智能上限,Harness决定工程下限。
把Harness做扎实了,模型才能跑得稳。
以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~
谢谢你看我的文章,我们,下次再见。
夜雨聆风