Locale: zh-Hans
※ 本文区分2026年10月4日时可核实的公开产品信息与实际使用体验。Astra、Codex、Claude Opus 5.5的公开能力以官方资料为准。“Astra容易扩大探索范围”“Dot适合做监督者”等说法只是特定工作流中的体验，不是通用跑分结论。本文中的Dot只是监督角色的称呼。
1. 结论：与其让一个AI包办，不如把角色拆开
AI越强，人越容易说一句：“全部交给你。”
调查、设计、改代码、测试、失败恢复、进度管理、最终说明，全塞进一个任务。
这其实是很多岗位。
一个实用的拆法是：
- 探索者：Astra — 找原因、替代方案、遗漏前提和架构风险
- 监督者：Dot — 控制范围、追踪状态、发现卡点、决定下一步
- 执行者：Codex — 做代码修改、文件处理、调查和测试
如果一个模型本身就能稳定从开始做到结束，那就不必强行组队。Anthropic把Claude Opus 5.5定位在智能体编程、复杂多工具任务和长时间工作等场景。[5]
所以原则不是“多智能体一定更高级”。
一个能收尾就用一个；一个会把工作越做越大，就拆角色。
2. 探索能力越强，有时越容易扩大范围
真正遇到未知问题时，探索型AI非常有用。
它会质疑前提，检查隐藏依赖，提出替代设计，继续追根因。
但如果“修一个按钮”也进入同样模式，就会变成：
“先重新看组件架构。” “相关服务也查一下。” “未来扩展性一起处理。” “顺便清理旧依赖。”
按钮还没修。
这不一定是模型不好，而是把“探索”和“完成”混成了同一个职责。
OpenAI Agents SDK把多个智能体的运行顺序和下一步决策称为orchestration，并区分由LLM决定流程和由代码决定流程两种主要方式。[1]
探索很重要，但不等于收尾。
3. Dot更适合当现场监督，而不是另一个天才
监督者最重要的不是提出最聪明的答案，而是知道：
- 现在做什么
- 什么已完成
- 什么失败了
- 下一步给谁
- 连续失败几次后升级
如果Astra说“我发现了一个更大的重构方案”，Dot可以说：“好，另开任务。现在先恢复服务。”
如果Codex测试失败，Dot把失败日志退回去。
连续三次同类失败，再交给Astra分析。
这就是监督层的价值。
4. 给Codex明确边界，执行会更稳定
给Codex的任务最好写清：
- 仓库
- 目标文件
- 当前症状
- 可修改范围
- 成功条件
- 必跑测试
- 返回格式
真实目标是让PR通过，就不要让它顺便思考公司的五年战略。
OpenAI公开的Symphony也强调把issue和task作为可持续的工作单位，而不是把某一次编程会话当成系统中心。[2]
聊天不是工作本体，task才是。
会话可以断。 模型可以换。 任务状态必须留下。
5. 只有thread_id不够，还要task_id
source_thread_id适合表示“最后回答回哪里”。
但一个线程里可能有多个问题。
因此至少要分开：
- task_id：这是什么工作
- source_thread_id：回答回哪里
- source_message_id：由哪条消息触发
- manager / executor / advisor
- status
- attempt
- next_action
状态可以从简单开始：pending、working、blocked、review、done、delivered、failed。
“应该做完了”不是状态。
6. 平时Dot↔Codex，真正卡住再找Astra
普通循环：
Dot → Codex → Dot → Codex
困难升级：
Dot → Astra → Dot → Codex
不要让Astra常驻每一步。
可以规定只在这些情况升级：
- 同一失败出现3次
- 有多个根因候选但无法区分
- 需要架构修改
- 跨多个仓库
- 需求与现有规格冲突
这样，最强的探索能力只用于真的需要探索的地方。
7. 临时高级套餐不要变成永久基础设施
现在能用的高级功能，不代表永远会用。
所以长期保存的应该是：
- task状态
- prompt
- 验收条件
- 测试方法
- 重试上限
- 升级规则
- 失败日志
高级模型可以是加速器，但别让它成为唯一知道流程的人。
换套餐后连业务流程一起失忆，这就太惨了。
8. 如果Opus 5.5能从0做到10，就别硬组AI公司
多智能体架构很有趣。
可以设主管、研究员、执行者、审核员。
然后人类发现自己成了机器人公司的行政总务。
这不是目标。
Anthropic把Opus 5.5描述为适合智能体编程、长时间代码任务和复杂多工具工作的模型。[5]
如果在你的真实环境里，它可以稳定完成：
目标 → 调查 → 实现 → 测试 → 修复 → 完成报告
那直接使用它往往更简单。
一个人能关单，就没必要成立AI集团。
9. 最小架构：共享队列 + 监督 + 执行 + 紧急升级
- 每个问题或故障带task_id进入队列
- Dot决定优先级和下一步
- Codex执行
- Dot检查结果
- 满足规则时才升级到Astra
- 最终回答回source_thread_id
- 确认delivered后关闭
- 真正端到端的任务可直接交给Opus 5.5
基础设施保存的是角色：
manager executor advisor
而不是某个具体模型名。
这样以后换模型也不会重做整个流程。
10. 总结：自动化不是AI越多越好，而是工作能自己结束
AI系统真正难的，往往不是“再想一点”。
而是决定什么时候停止思考，进入执行。
探索者扩大地图。 监督者关闭循环。 执行者真正动手。
分工后，交流会变成：
Astra：“找到7个方案。” Dot：“只验证第2个。” Codex：“已修复，测试通过。” Dot：“关闭。”
突然就像一家公司。
Keep the loop tight.
AI数量不是自动化程度。
不用人反复救场，任务也能到达可验证的结束状态，这才是自动化。
