在特定（源码解析）任务上，通用agent为什么比不过专用的？
0
[待解决问题]
背景是这样，我想对某个大型项目做源码解析，生成类似于《ClaudeCodeC源码解析》的一本书。
我先写了个skill（
https://github.com/DracoUnion/skills/tree/master/write-code-anls），拿ClaudeCode去跑，结果只得到了10章少于十万字的内容。这肯定覆盖不了全部源码。
然后我试着把整个流程拿Python调用OpenAI API 写成CLI应用（
https://github.com/DracoUnion/BookerGptTool/blob/master/BookerGptTool/code2book.py），结果生成了90多章的内容，覆盖了全部源码文件。
为什么会这样，难道是我Skill写的不好或者通用agent本来就有缺陷吗？
所有回答(2)
0
不是你 Skill 写得不好，是通用 Agent 的运行机制决定的。
核心差异在遍历策略的控制权。
你的 Python CLI 脚本大概率做了显式的文件遍历——递归走完每个源码文件，逐个调 API 生成章节，所以 90+ 章一个不漏。这是程序控制流程，覆盖率由你的遍历逻辑保证。
而 Claude Code 走的是 Agent Loop：模型自己决定下一步读哪个文件、什么时候算"够了"。面对大型项目，模型的 context window 会很快被源码撑满，于是它开始做信息压缩——跳过它认为"不重要"的文件、合并相似模块、用抽象概括代替逐文件分析。10 章 < 10 万字，就是模型自己做了裁剪决策的结果。
这不是缺陷，是通用 Agent 的设计取舍：它优化的是对话效率，不是穷举覆盖率。Claude Code 的 system prompt 和 tool use 模式天然倾向于"用最少步骤完成任务"，而不是"遍历每一个文件"。
解决思路：如果你要用 Agent 做穷举式源码解析，关键是在 Skill 里强制显式遍历逻辑——比如先列出全部文件清单，然后逐个文件 obligate 模型生成独立章节，不给它跳过的自由度。把 Agent 当执行者而不是决策者，覆盖率就上来了。
0
这并非你的 Skill 写得不好，也不是通用 Agent 有根本性缺陷，而是“交互式 Agent（如 Claude Code）”与“批处理式脚本（如你的 Python CLI）”在处理大规模上下文任务时的底层逻辑差异导致的。
简单来说：Claude Code 被设计为“对话者”，受限于实时交互的上下文窗口和注意力机制；而你的 Python CLI 是“流水线工人”，通过强制分片和状态重置，规避了长程记忆的衰减。
