前段时间又把未完成的AgentCLI翻出来继续vibe了一下.
主要是GPT 5.6出来了,顺手当作测试.
而且也确实有一些新的想法.
比如在模型能力持续增长的情况下,Agent Loop这类概念应该也是会像prompt/skill之类的被渐渐内化的.
而且本质说来说,loop不loop其实还是一个workflow的问题.
而这个问题DSL算是最直接的解决方案了.
所以就打算让AI写个(ASL)Agent Script Language.
然后用这个ASL去生成workflow/loop,程序化地跑起来.
核心就是两个个meta function,session和llm.
sessino用户生成独立上下文.
llm接受session和prompt,约定一个返回类型.
大致比如
···rust
let session = session()
loop {
let review = llm(session,"review this project")
if review == "ok" {
break;
}
....
}
...
···
这里有个小插曲就是一开始没切model.
默认让v4 flash跑的.
然后发现它思考了下,开始自己创造parser和一些基本的condition expr.
出来的版本至少compile和简单的run是没什么问题.
不过还是比较primitive,以及语法特性其实也还不够丰富.
发觉模型没切之后换到gpt 5.6思考了下倒是知道一个叫rhai的库.
确实一下让实现的工程性提高了不少层次.
原本可能需要实现一套语法的,现在变成了直接是rust script加核心的几个meta host function就行了.
这里模型内嵌知识量的差距就出来了.
而且这个方案的优势可能是容易被llm理解.
因为不是什么独创语法,所以更容易被正确地生成合法的script.
不过这都是建立在这个东西最终可用的基础上.
这里想说的是一个测试过程发现的感觉比较有意思的点.
在eat dog food的测试里prompt让llm去review当前project,以让它更现代化和agent友好.
然后看了下gpt 5.6生成的rhai.
主要是四个独立的session/context.
architecture reviewer.
safety and correctness reviewer
agent experience reviewer.
还有最后一个implementer,把前面几个personality/role的输出拼接到成一个大的context.
流程上说一系列的pre build check和implementer session.
以及对应的post check/verify以及可能的error recovery routine.
大致来说,基本可以认为agent能力是内化到模型自身了的.
有没有专门的agent loop支持理论上来说区别可能都不大.
要说唯一可能的区别就是agent tool可能因为上下文物理隔离/没那么长了,所以同样的参数设置下能主动生成的长度更长更持久罢了.
而可能的副作用也正是由于上下文隔离,可能有些东西会反复被subagent重新发现/产生矛盾决策/选型.
接着是同样的prompt给opus 4.8.
session使用上大致跟gpt 5.6是一致的.
也是
modernizer.
agentizer.
safety.
documentation.
稍有不同的是会由独立的architect,把上面的组成一个大的context.
然后proposed agent把architect的写成文档记录.
所以从行为上来说,这也比较符合anthropic一直鼓吹的plan first类似.
属于把文档当checkpoint/offload上下文的做法.
另外一个跟gpt 5.6的区别就是多了一些helper function.
主要是用来做一些read/write工具容错的.
基本上是用于捕获异常状态/原因.
所以某种程度上也是为了丰富上下文明细的.
而且有一点跟当初Claude Code Leak的prompt一致的就是,会有一段捕获当前系统状态,
包括git提交commit,文件目录结构,配置快照,塞到每个session的system prompt里的行为.
所以从这个角度上来说,opus可能对于上下文的完整度比gpt 5.6有着更苛刻的要求.
接着可能是更加有趣的国产模型的一些行为表现.
首先是v4 flash.
v4 flash生成形式上来说跟gpt 5.6和opus 4.8的是相似的.
之所以说是相似是因为它有个比较严重的问题.
从行为上来说,v4也是产生了几个独立session.
但不是分角色,而是分模块地去分析.
这点跟使用它的感受是一致的.
就是很少会真地去delegate到agent,基本上都是要在同一个context里尽可能完成所有事情.
或者说,它的delegate意识不是按照角色/目标这种逻辑切分的.
而是简单的scale out的切分.
然后逻辑上来说它应该是准备gather这几个分模块的输出汇总到一个planer里.
类似gpt 5.6/opus 4.8那种大context解决问题.
甚至于它的结构可能是最优的.
因为是很典型的效率为先的fork-join-fork的并行模式.
即
```
for crate in 0..crate.len(){
let session = session()
sessions.push(session.llm(...))
}
let plan = session()
...
for step in 0...steps{
let worker = session()
workers.push(worker.llm(...))
}
// verify
...
```
这种形式上并行化的处理方式.
看起来很promising.
但是它的问题是,plan哪个session其实并没有把按模块的信息汇总拼接起来处理.
也就是说,v4 flash虽然可能很聪明,但是会存在注意力缺失的问题.
比如这个例子里就把critical的汇总部分给遗忘了.
导致前面都变成的无效token消耗.
完美不会对后续产生任何增益.
感觉这个可能是跟deepseek的几个重要工程优化,比如DSA带来的副作用了.
这个就可能导致有时候觉得多快好省.
有时候又不太理想的原因.
剩下两个要放一起的是glm 5.2和kimi 2.7 code.
之所以要放在一起是因为它们的输出跟前面三个是完全不一样的.
从用户角度来说,属于意图识别错误.
而且有趣的是,错误的方向都是一致的.
前面说了,prompt是review当前project,以让它更现代化和agent友好.
kimi和glm有点不约而同地把agent友好理解为让项目维护更容易被agent接入.
而不是项目本身,作为一个agent cli也好,一个ASL plugin/扩展也好,更容易被其他agent工具接入.
这个往好点说,就是用kimi和glm可能对怎么写mcp之类的会更有想法.
毕竟之前作model tone比较大时候,kimi确实会更喜欢有事没事用tools解决.
抛开生成的脚本目的来看,单谈结构.
kimi的会更类似opus.
subagent的输出一般都会写成文档.
或者说kimi更喜欢通过文件交互.
比如像为了让agent更容易参与到代码提交,写了一个CONTRIBUTING.md.
又专门的agent guideline章节.
而这个文件是直接在脚本里通过write file写出去的.
而不是通过比如可能opus的话会开个subagent去做这个事情.
所以这里的行为其实有点类似v4 flash.
也是什么都在一个context搞定.
但是会留存记录.
可能是作为一个agentic fallback交流机制?
而glm 5.2与其说也是类似opus不如说是更像claude code.
因为它也是会把一些固定context追加到每个session里.
加上它也是喜欢把subagent的输出写到一个文件.
所以形式上来说,glm更像是opus的某种全方位行为趋同.
因为虽然kimi也会追加上下文.
但一方面kimi较少直接subagent.
另一方面,唯一的一次subagent也是当作某种高级的tools调用的.
或者类似explore agent的使用.
不管怎么样,总的来说,Agentic/Harness这个东西,在外围可能确实没什么能做的了.
