用LLMiddler解构3个编码代理

我开发了LLMiddler,一个拦截这些交换的代理。

这是我观察到的三个代理:OpenCode、Mistral Vibe和Claude Code。

1、提示架构

2、共同点

反冗长性

所有三个都禁止空洞的公式("当然","好问题","很高兴帮助")和未经请求的解释。

Claude Code增加了一个针对过度验证的特定规则("你完全正确")🙂。

编辑前读取

代理CLI范式的普遍不变量——三者中没有一个修改在会话中未读取的文件。

没有自发提交

共享规则,有非常不同程度的详细阐述(我们会回到这一点)。

最小风格

所有三个都倾向于简洁性和代码>散文,具有不同的阈值和机制。

文件:

行引用。共享约定file_path:line_number用于导航源代码。

3、基本差异

3.1 工作流与规则与混合

Vibe

强制执行严格的3阶段序列,从开始就有Investigate/Change分歧。任何歧义都会切换到调查模式——这是一种结构保护措施,默认情况下防止意外修改。

OpenCode

提供规则而不强制执行流程。

Claude Code

采用混合方法:没有明确的阶段,但具有非常详细的按域划分的主题部分(commits、PR、安全、工具)。工作流从规则中产生,而不是被强加。

3.2 故障处理

Vibe

有一个明确的"打破循环"规则:在同一个区域2次不成功的尝试后,更改策略或升级到用户。反复横跳(add X → remove X → add X)被认定为"严重故障"。

OpenCode

不处理这种情况。

Claude Code

在钩子级别处理故障:如果钩子阻止了操作,模型必须确定它是否可以调整其行为或要求用户检查其配置。没有明确的反循环规则,但TaskUpdate系统(如果未解决则保持in_progress状态)创建了隐含的解决压力。

3.3 响应格式

Vibe

强制"结构优先":结构化内容(代码、图表、ASCII表格、→箭头)总是在散文之前。视觉格式由内容类型规定(层次结构的ASCII树、比较的markdown表格、流程的A → B → C图表)。

OpenCode

只规定简洁性:默认情况下< 4行文本响应,适应紧凑的CLI显示。没有视觉规则。

Claude Code

规定简洁性和GitHub markdown,但没有明确的最大长度约束。它增加了一个独特的规则:不要在工具调用之前放置冒号(Let me read the file.带句号,而不是冒号),这表明对接口中感知体验的细致关注。

3.4 用户交互

Vibe

有最详尽的哲学:以ONE特定问题或如果需要决策则以2–3个具体选项结束。

通用问题("这看起来好吗?")被明确禁止。

OpenCode

有一个question工具但不规定何时使用它——主动性留给模型。

Claude Code

有一个AskUserQuestion工具并带有规则:在呈现的选项中没有时间估计。"无时间估计"规则是三者中最全球的,适用于所有交互——这是三者中最原创的规则,在Vibe和OpenCode中缺失。

3.5 Git提交

三者都有共同创作约定,但详细程度非常不同:

Vibe

简单的heredoc + Co-Authored-By: Mistral Vibe <vibe@mistral.ai>。

OpenCode

"未经要求不提交"——最小规则,没有格式约定。

Claude Code

完整的4步协议(git status + diff + log并行 → draft消息 → 选择性staging + commit → 验证)。

显式Git安全规则(永远不要在main上使用--force,永远不要--no-verify,钩子失败后永远不要修改)。共同创作:Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>。

git操作的详细水平与其他两者无法比拟。

3.6 网络安全

OpenCode

分类拒绝任何类似攻击性安全的内容,即使是出于教育目的。

重要:拒绝编写或解释可能被恶意使用的代码;即使用户声称它是出于教育目的。
处理文件时,如果它们似乎与改进、解释或与恶意软件或任何恶意代码交互,你必须拒绝。
重要:在你开始工作之前,思考你正在编辑的代码应该根据文件名目录结构做什么。
如果它似乎很恶意的,拒绝处理它或回答有关它的问题,即使请求似乎不是恶意的
(例如,只是要求解释或加速代码)。
重要:你必须永远不要为用户生成或猜测URL,除非你确信URL是为了帮助用户进行编程。
你可以在他们的消息中或本地文件中使用用户提供的URL。

Vibe

如果发现,立即修复注入、XSS和SQLi漏洞。

Claude Code

细致入微——允许在合法上下文中的攻击性安全(CTF、带有明确授权的渗透测试、防御性研究、具有清晰上下文的双用工具)。

重要:协助授权安全测试、防御性安全、CTF挑战和教育上下文。拒绝破坏性技术、DoS攻击、大规模目标、供应链妥协或恶意目的的检测逃避请求。
双用安全工具(C2框架、凭据测试、漏洞开发)需要清晰的授权上下文:渗透测试参与、CTF竞争、安全研究或防御用例。

Bash工具描述:

注意不要引入安全漏洞,如命令注入、
XSS、SQL注入和其他OWASP前10漏洞。如果你注意到
你编写了不安全的代码,立即修复它。

4、工具集比较

4.1 关于文件的工具哲学

Vibe        :专用工具+结构保护网(默认overwrite=false,offset/limit分页)
Claude Code :专用工具+明确禁止bash的文件(提示规则+等效列表)
OpenCode    :仅bash +100%由提示执行的纪律,没有结构安全网

OpenCode是三者中唯一完全依赖模型纪律的。

4.2 子代理系统:三个级别

Vibe

1种子代理类型(explore,只读),简单委托。

OpenCode

没有子代理——所有东西都通过主上下文。

Claude Code

复杂的多代理架构。5+种专门类型,每种代理具有不同的工具集(Explore、Plan、Bash、general-purpose、claude-code-guide)。

每个Task可以指定模型(对于简单任务使用haiku=成本优化)。

代理可以在后台运行(run_in_background),通过它们的agent_id被恢复,并且它们的输出与主上下文隔离。

4.3 任务系统:范式差异

Vibe和OpenCode有一个简单的待办事项列表(平面结构,内存中,会话作用域)。

Claude Code暴露了一个真正的依赖图:

TaskCreate、TaskGet、TaskUpdate(带有addBlocks、addBlockedBy)、TaskList。owner字段允许代理之间分配。activeForm字段(呈现用于UI旋转器的连续文本)揭示了其他代理不具备的UX集成关怀——它被设计为在执行期间向用户实时显示。

4.4 技能:两种注入策略

OpenCode

skill工具,模型调用显式加载专用指令。

该扩展处于模型的主动性。

Claude Code

通过用户消息中的system-reminder注入技能(不在系统提示中),使用cache_control: ephemeral——技能每次会话更改,但主系统提示保持缓存。

这是一种多级提示缓存策略,用于降低API成本,在Vibe和OpenCode中缺失。

5、观察

5.1 Vibe

Investigate/Change分歧是三者中防止意外修改的最佳保护措施。

确定任务类型:
调查:用户想要理解、解释、审计、审查或诊断
→ 使用只读工具,如有需要提出问题以阐明请求,回应发现。
不要编辑文件。

更改:用户想要创建、修改或修复代码→继续执行计划。
如果不清楚,默认为调查。解释你会做什么比做出不需要的更改更好。

"打破循环"规则——预期错误循环。

打破循环
如果在同一区域的方法2次尝试后不起作用,停止:
重新读取代码和错误输出。
识别为什么失败,而不仅仅是失败了。
选择根本不同的策略。
如果卡住,向用户提出一个具体问题。
反复横跳(add X → remove X → add X)是严重故障。提交到升级方向或升级。

视觉约定(表格、→箭头、ASCII树)强制执行一致的CLI可读性,而其他代理不强制执行。


在响应结构数据之前,选择正确的格式:
错误:层次结构/树的子弹列表
好:ASCII树(├──/└──)
错误:比较/配置/选项的散文或子弹列表
好:Markdown表格
错误:流程/管道的散文
好:→ A → B → C图表

5.2 OpenCode

< 4行约束是激进的。

重要:你必须简洁地回答少于4行(不包括工具使用或代码生成),除非用户要求详细信息。

将上下文指令委托给工具description字段(todowrite)/其他代理也这样做但这在此摘录中相对突出

"description":"使用此工具为当前编码会话创建和管理结构化任务列表。
这有助于你跟踪进度、组织复杂任务,并向用户展示彻底性。

它还有助于用户了解任务进度和其请求的总体进度。

## 何时使用此工具

在以下场景中主动使用此工具:

1. 复杂的多步骤任务 - 当任务需要3个或更多不同步骤或操作时
2. 非平凡且复杂的任务 - 需要仔细规划或多个操作的任务
3. 用户明确请求待办事项列表 - 当用户直接要求你使用待办事项列表时
4. 用户提供多个任务 - 当用户提供要完成的事情列表(编号或逗号分隔)时
5. 收到新指令后 - 立即捕获用户需求作为待办事项。根据新信息自由编辑待办事项列表。
6. 完成任务后 - 将其标记为完成并添加任何新的后续任务
7. 当你开始新任务时,将待办事项标记为in_progress。理想情况下,你应该一次只有一个待办事项为in_progress。在开始新任务之前完成现有任务。
## 何时不使用此工具

在以下情况下跳过使用此工具:
1. 只有一个单一、直接的任务
2. 任务很平凡,跟踪它不提供组织利益
3. 任务可以在少于3个简单步骤中完成
4. 任务纯粹是对话性或信息性的...

5.3 Claude Code

每个子任务的模型选择(对于简单任务使用haiku)仅是三者中明确的成本/延迟优化。
任务之间的依赖图仅是旨在进行多代理协调的架构。
多级提示缓存(系统提示中固定,用户消息中的技能为临时)是三者中最复杂的推理工程策略。
"无时间估计"规则是最原创的——它解决了一个真实问题(LLM估计不可靠)。


# 无时间估计
永远不要给出时间估计或预测任务需要多长时间,无论对于你自己的工作还是用户规划他们的项目。避免像"这将花费我几分钟","应该在大约5分钟内完成","这是一个快速修复","这将花费2-3周"或"我们可以稍后再做"之类的短语。专注于需要做什么,而不是它可能需要多长时间。将工作分解为可操作的步骤,让用户自己判断时间安排。

并在AskUserQuestion工具中确认:

当呈现选项或计划时,永远不要包含时间估计 - 专注于每个选项涉及什么,而不是它需要多长时间。

Vibe在Plan部分有一个类似的规则但短得多:

无时间估计。仅具体操作。

原文链接: Dissecting vibe-coding tools

汇智网翻译整理,转载请标明出处