Agent需要什么样的基础工具集合

看到大家在聊Agent工具集的问题——是不是提供一个shell就都搞定了？做了holon之后发现，其实没有那么简单。
读：为什么放弃了Read/Glob，全走shell
holon的工具集改了几个版本，最后废弃了类似Claude Code提供的Read（读文件）、Glob（模式搜索）这类专用工具，读取和查找全部通过shell来完成。这和Codex的路线一致——Codex的ExecCommand一把梭，读文件就是cat，搜代码就是rg，不再单独给每种"读"操作定义一个工具。
这样做的理由很朴素：shell是LLM最熟悉的"编程语言"。与其让模型去学你定义的Read工具的参数语义，不如直接让它写已经训练了几十亿次的shell命令。每多一个专用工具，模型的认知负担就加一层；而shell这个界面，模型已经足够熟练了。
但全走shell有一个代价：输出截断。框架为了避免shell返回值太长撑爆上下文，会给每个命令设输出上限。Agent用cat读一个大文件，可能只拿到前半截，剩下的在artifact文件里，还得再cat一次甚至多次才能读完。Claude Code的Read工具压缩阈值比通用shell高很多，读大文件一步到位，少了好几个来回。本质上是取舍：少定义工具降低认知负担，但专用工具在边界场景效率更高。
写：从sed到ApplyPatch，以及free grammar tool的难题
但写操作就无法完全用shell搞定。
如果让Agent全用sed做编辑，就会发现遇到复杂的多行匹配很难处理——换行、转义、缩进，任何一层出了问题都会导致编辑失败。所以很多系统会提供Replace String这样的编辑工具，让Agent传一大段old_string来精确匹配并替换成new_string。虽然笨拙，但比sed稳得多。
Codex则走得更远，发明了自己的ApplyPatch工具，让Agent直接生成patch，一次搞定批量编辑。holon就借鉴了这个思路。
但落地的时候踩到一个坑：Codex用的是一套OpenAI自己定义的简化patch格式，并且搭配了一种叫做free grammar tool的特殊工具机制来解决格式传递问题。
为什么要专门搞一种新机制？因为LLM的标准工具定义都是tool(args)这种JSON参数格式。如果把patch作为JSON字符串参数传递，会牵扯到大量的转义——换行要变成\n，引号要加反斜杠，缩进也得小心处理。Agent写patch时本身就容易出错，再叠一层JSON转义，出错概率翻倍。free grammar tool的思路是把patch的原始文本直接作为tool的输入体，不经过JSON参数编码，模型写什么就是什么。这大幅降低了模型生成patch时的出错率。
而这套机制目前只有OpenAI的Codex接口支持。holon是要兼容多模型提供方的，没法只靠这一条路。
于是holon的做法是：根据模型注入不同的ApplyPatch定义。对支持free grammar的模型，直接走原始patch格式；对其他模型，就接收标准的git diff格式。我觉得LLM经过GitHub上几十亿次diff的训练，对git diff格式应该相当熟练。实践下来效果还可以——虽然也常出错，但多数时候能改对，而且随着训练数据积累，这个能力只会越来越好。不过我还是建议各家模型厂商都支持一下free grammar tool，这对Agent写代码的场景确实是刚需。
调度：长时间命令和task抽象
第三个问题是Agent执行的shell命令不一定会很快结束——启动dev server、跑测试、构建项目，都可能跑很久，甚至根本不退出。早期的Agent框架处理得很粗暴：要么同步阻塞把自己卡死，要么所有命令一律丢后台，结果Agent把同一个命令反复执行很多遍。
现在业界逐渐收敛到一个基本共识：不给Agent暴露"前台/后台"的选择——这件事Agent自己判断不准。更好的方式是设置一个时间阈值，命令超时自动转后台，对Agent完全透明。Agent不需要预判这个命令该不该放后台，runtime自己处理就行。
但自动转后台只是第一步。转后台之后，真正的工程问题才浮出来——而这些问题，目前业界还没有标准答案。
首先是输出怎么读。后台任务可能还在跑也可能已经结束，输出可能很大。但各家API的语义并不统一——有的走轮询，有的走事件推送。
其次是任务怎么停。各家都有取消机制，但取消是即时kill还是优雅退出、已产生的部分输出要不要保留？
最后是谁来叫醒Agent。Agent把任务丢后台以后休眠了，任务结束那一刻谁来叫醒它？这要求runtime和Agent调度深度绑定，不是独立工具层能解决的。
这三件事——读输出、停任务、叫醒Agent——合在一起，就是后台任务完整的生命周期管理。各家都实现了"能后台跑"，但管理面还没有标准化方案，这可能是下一阶段Agent工具链演进的关键节点。
还没到无脑用一个现成模式的时候
所以回到开头的问题：shell能解决80%，但剩下20%——编辑的精确性、patch格式与模型能力的匹配、长任务的调度抽象——恰恰决定了Agent能不能从demo走向真正可用的系统。
工具集的选择远不止"封装一个shell"那么简单，也远没到大家可以无脑套用一个现成模式的时候。这也是为什么Codex和Claude Code在这些基础问题上给出了不同的答案，而holon又根据自己的场景做了不同的取舍，这中间可以探索和改进的点，还很多。