Agent Team
Orchestrate a dynamic team of agents: one Orchestrator (opus) plans + delegates + synthesizes; multiple Worker agents (sonnet) execute specialized subtasks and communicate bidirectionally.
Architecture
CODEBLOCK0
Workflow
Step 1 — Orchestrator Plans the Team
Analyze the task and define 2–4 worker roles. Each role needs:
- - Name: short label (e.g.
researcher, coder, reviewer) - Task: specific, scoped instruction
- Inputs needed from other workers: what it needs to receive before finishing (for bidirectional flow)
See references/role-patterns.md for common role combinations per scenario.
Step 2 — Spawn Workers
Spawn each worker as a persistent sub-agent session. Always set streamTo: "parent" so the user sees real-time output in their chat window:
CODEBLOCK1
Spawn all independent workers in parallel (single tool call block). Only spawn sequentially when a worker strictly depends on another's output.
Step 3 — Bidirectional Communication
Workers can message each other via sessions_send. The orchestrator:
- 1. Gives each worker the session keys of peers it may need to consult
- Monitors via
subagents(action=list) — check on-demand, not in a loop - Can steer any worker mid-task: INLINECODE7
Direct worker-to-worker message pattern:
CODEBLOCK2
Step 3.5 — Relay Progress to User (Orchestrator Broadcast)
After each worker completes, send a status update to the user before moving on:
CODEBLOCK3
This gives the user full visibility into the team's progress without needing to check logs manually.
Step 4 — Aggregate Results
Once all workers report back, the orchestrator:
- 1. Synthesizes outputs into a coherent final answer
- Resolves conflicts between workers' findings
- Delivers structured report to the user
Model Config
| Role | Model | Rationale |
|---|
| Orchestrator | Current session model (Jarvis / Friday / Jupiter) | Complex planning + synthesis |
| Workers |
sonnet | Cost-efficient execution |
Orchestrator identities:
- - Jarvis — technical tasks (code, architecture, systems)
- Jupiter — trading strategy, quant analysis
- Friday — admin, research, daily tasks
Override worker model when a subtask needs deeper reasoning: pass model="anthropic/claude-opus-4-6" to that specific spawn.
Common Scenarios
See references/role-patterns.md for ready-made role sets:
- - Code review:
reader + security-reviewer + INLINECODE13 - Market research:
data-analyst + sentiment-analyst + INLINECODE16 - Trading signals:
technical-analyst + fundamental-analyst + INLINECODE19
Key Rules
- - Spawn independent workers in one parallel block — never sequential unless there's a hard dependency
- No tight poll loops — use
subagents(action=list) only when checking status on-demand - Session cleanup: after aggregation, kill idle workers with INLINECODE21
- Scoped tasks: each worker gets a single, well-defined responsibility — avoid overlap
- Context isolation: workers don't share the orchestrator's full context; pass only what's needed
Agent Team
编排一个动态的智能体团队：一个编排者（opus）负责规划、委派和综合；多个工作智能体（sonnet）执行专业化的子任务并进行双向通信。
架构
用户
└─► 编排者 (opus)
├─ 动态规划团队组成
├─ 生成工作智能体 A (sonnet) ──┐
├─ 生成工作智能体 B (sonnet) │ 双向通信
├─ 生成工作智能体 C (sonnet) ◄─┘ 通过 sessions_send
└─ 汇总 → 向用户输出最终报告
工作流程
步骤 1 — 编排者规划团队
分析任务并定义 2-4 个工作角色。每个角色需要：
- - 名称：简短标签（例如 研究员、编码员、审查员）
- 任务：具体、限定范围的指令
- 需要从其他工作智能体获取的输入：完成前需要接收的内容（用于双向流程）
常见角色组合请参见 references/role-patterns.md。
步骤 2 — 生成工作智能体
将每个工作智能体生成为一个持久的子智能体会话。始终设置 streamTo: parent，以便用户在聊天窗口中看到实时输出：
python
伪代码 — 使用 sessions_spawn 工具
sessions_spawn(
task=你是 [角色] 智能体。[具体任务]。
当你需要从其他智能体获取输入时，向会话 [SESSION_KEY] 发送消息。
清晰结构化地报告你的最终结果。,
runtime=subagent,
mode=session, # 持久化 — 可以接收后续消息
model=sonnet, # 工作智能体使用 sonnet
label=worker-[角色],
streamTo=parent # 实时将输出流式传输到用户聊天窗口
)
并行生成所有独立的工作智能体（单次工具调用块）。仅当某个工作智能体严格依赖另一个的输出时才按顺序生成。
步骤 3 — 双向通信
工作智能体之间可以通过 sessions_send 相互发送消息。编排者：
- 1. 为每个工作智能体提供可能需要咨询的同伴的会话密钥
- 通过 subagents(action=list) 进行监控 — 按需检查，不循环
- 可以在任务执行过程中引导任何工作智能体：subagents(action=steer, target=<标签>, message=<重定向指令>)
工作智能体之间的直接消息模式：
工作智能体 A 完成部分结果
→ sessions_send(sessionKey=工作智能体-B-key, message=这是我的输出：...)
工作智能体 B 整合结果，完成
→ sessions_send(sessionKey=编排者-key, message=完成：...)
步骤 3.5 — 向用户传递进度（编排者广播）
在每个工作智能体完成后，继续下一步前向用户发送状态更新：
[工作智能体-研究员] 完成 ✅ — 找到 12 条相关数据，传给工作智能体-分析师
[工作智能体-分析师] 处理中... 等待工作智能体-研究员结果
[工作智能体-审查员] 完成 ✅ — 发现 3 个风险点
这使用户无需手动检查日志即可全面了解团队的进度。
步骤 4 — 汇总结果
当所有工作智能体报告完成后，编排者：
- 1. 将输出综合成连贯的最终答案
- 解决工作智能体发现结果之间的冲突
- 向用户提供结构化报告
模型配置
| 角色 | 模型 | 理由 |
|---|
| 编排者 | 当前会话模型（Jarvis / Friday / Jupiter） | 复杂规划 + 综合 |
| 工作智能体 |
sonnet | 成本效益高的执行 |
编排者身份：
- - Jarvis — 技术任务（代码、架构、系统）
- Jupiter — 交易策略、量化分析
- Friday — 管理、研究、日常任务
当子任务需要更深层次的推理时，可以覆盖工作智能体模型：在相应的生成调用中传递 model=anthropic/claude-opus-4-6。
常见场景
现成的角色组合请参见 references/role-patterns.md：
- - 代码审查：阅读者 + 安全审查员 + 重构规划员
- 市场研究：数据分析师 + 情绪分析师 + 风险评估员
- 交易信号：技术分析师 + 基本面分析师 + 宏观观察员
关键规则
- - 在一个并行块中生成独立的工作智能体 — 除非存在硬依赖，否则绝不按顺序执行
- 无紧密轮询循环 — 仅在按需检查状态时使用 subagents(action=list)
- 会话清理：汇总后，使用 subagents(action=kill, target=<标签>) 终止空闲的工作智能体
- 限定范围的任务：每个工作智能体承担单一、明确的责任 — 避免重叠
- 上下文隔离：工作智能体不共享编排者的完整上下文；只传递必要的内容
