Mistral 于 2026 年 1 月 27 日发布 Vibe 2.0，官方重点包括自定义子代理、多选澄清、斜杠命令技能和统一 agent modes。厂商演示或少量试用不能当作普遍生产结论。我的判断是：子代理本身不会自动提高可靠性；它的价值取决于任务边界、权限和验证是否更清楚。

子代理首先是接口

“代码审查代理”不应只是另一个更长的 prompt。它需要明确输入：变更范围、仓库规范、基准提交与允许读取的文件；明确输出：按严重度排序的问题、证据位置与无法确认的事项；明确权限：只读，不得修改文件或执行发布。若输入是“看看仓库有没有问题”，子代理只会把主代理的歧义复制一遍。

可以先设计三个窄角色：探索者只收集相关文件和约束；实现者只修改已批准范围；验证者只运行指定检查并解释失败。它们通过小型结构化交接共享事实，不共享无限聊天历史。一个角色完成时返回已检查内容、结论、未决风险和建议下一步，主流程再决定是否继续。

澄清是可靠性功能

Vibe 2.0 的多选澄清值得关注，因为终端代理最危险的失败经常来自它执行了一个合理但错误的解释。澄清问题应落在会改变实现或副作用的分叉：覆盖还是合并配置、只修错误还是重构模块、是否允许安装依赖。命名、格式等可从仓库发现的事项不必每次打断用户。

把澄清选项写成互斥结果，并说明影响。收到答案后将决定写入任务状态，避免不同子代理再次询问或采用相反假设。若代理已经可以通过只读检查确定答案，就先检查；澄清不是逃避探索的借口。

技能负责可重复流程

斜杠技能适合封装团队重复且可审查的步骤，例如发布前检查、数据库迁移审计或依赖升级。技能应固定输入、命令顺序、停止条件和交付证据，而不是隐藏一个无限权限的 shell 模板。版本与仓库一起管理，变更通过代码审查。

不要把密钥、个人路径或生产主机写进技能。命令参数来自显式配置并校验；默认只读；涉及发布、删除和权限变化时在行动前请求人类批准。工具输出可能包含网页或依赖中的恶意指令，代理只能把它当数据，不能让输出改变既定权限。

Mode 应表达权限而非人格

“快速模式”“认真模式”很难验证，而“只读诊断”“可编辑但不安装”“允许运行测试”更清楚。每个 mode 列出可用工具、可写目录、网络访问和需要批准的动作。模式切换记录在日志中，并在提示区让用户看到当前能力。

自定义子代理必须继承或收窄父级权限，不能因委派获得更宽权限。并行代理也要避免同时修改同一文件；可以先并行分析，再由一个所有者合并。否则所谓并行会把冲突和重复工作转移给用户。

用同一组任务测量

准备真实但可恢复的仓库任务：单文件 bug、多模块改动、含歧义需求、失败测试和恶意 README 指令。比较单代理与子代理工作流的任务成功率、无关改动、测试证据、澄清次数、token、耗时和人工纠正次数。每个配置重复运行，不能用一次成功展示下结论。

失败分类比总分有用：遗漏规范、错误修改、未验证、权限越界、循环委派或上下文丢失。若子代理提高成功率却让成本和等待不可接受，它可能只适合高风险任务。若只读审查更稳，可以保留该角色而不把所有工作都多代理化。

结论

Vibe 2.0 的自定义子代理、澄清、技能和 modes 提供了更清楚的编排原语。可靠性来自把它们用于窄合同、最小权限、单一写入所有者与可复现评测，而不是角色越多越好。在正式纳入日常开发前，先让每个代理能说明输入、输出、权限和完成证据；无法写清这些边界的任务，拆成子代理只会增加不确定性。