多 Agent 与编排
子代理优先、框架按需、A2A、多渠道接入
- 01 为什么要多 Agent，以及为什么别急着上框架
单体 Agent 在生产里为什么脆——上下文爆、职责混、难调试。多 Agent 是微服务化的解法，但 2026 的共识是「先用裸 SDK 把协调学会，真需要显式状态机和检查点了再上重框架」。给你一张「该不该拆」判断清单，和一个一上来就上 LangGraph 把简单事搞复杂的反面教训。
- 02 编排成本心智：子代理(便宜) vs 对话式(贵) vs handoff(居中)
多 Agent 编排的钱花在哪？用「调研+写报告」这一个具体任务，把子代理委派、对话式多 Agent、handoff 三种模式的 token 量级和调用数分别估出来，给你一张成本对照表和一棵「按成本选编排模式」的决策树，再附一段可读的子代理委派代码示例。
- 03 裸 SDK 手搓编排：用子代理拆活、并行、隔离上下文
不上 LangGraph、不上 CrewAI，直接用 Claude Agent SDK 的子代理原语做编排。讲清子代理的四个用武之地（上下文隔离/并行/专门指令/工具限制），给一段主 Agent 派两个子 Agent 并行干活再汇总的完整代码骨架，附「你应该看到什么」、子代理委派失败排查清单、串行 vs 并行变体和动手挑战。
- 04 子代理零上下文成本：拆解 hermes-agent 的 subagent + Python RPC 流水线
主 Agent 一边干活上下文一边膨胀、越跑越笨？拆解 hermes-agent 的隔离子代理设计——子代理有自己的对话和终端、跑 Python RPC 把多步流水线折叠掉，主 Agent 只拿一行结果。附一段不依赖 hermes 本体、用标准库就能真跑的最小实现。
- 05 A2A 协议：让 Agent 之间互相发现与委派
你的 Agent 想把一段活甩给别人家的 Agent，怎么知道对方会干什么、怎么触达、要不要鉴权？A2A（Agent-to-Agent）用一张「agent card」解决跨框架协作。拆解 agent card 字段、发现到委派的全过程，讲清 A2A 和 MCP 到底有啥不一样。
- 06 多渠道接入：拆 hermes gateway 与 openclaw SOUL.md，把 Agent 接进微信飞书
Agent 写好了却只能在你自己的终端跑，没人用。拆解两种"把 Agent 接进用户已在用的渠道"的开箱方案——hermes 的单进程多渠道 gateway、openclaw 的 SOUL.md 配置驱动；给一份 SOUL.md 字段示例 + 接渠道的最小思路 + 国内接微信飞书的现实坑（合规/封号/个人号风险）。
- 07 什么时候才上 LangGraph：需要显式状态/检查点/复杂图的时候
别一上来就上编排框架。这篇讲清「延迟框架」原则的延续——多数活裸 SDK + 子代理就够；再给你一份「上框架前的 3 个必答问题」决策清单和 LangGraph vs 裸 SDK 取舍表，帮你判断什么信号出现时才该上 LangGraph，顺带说清 CrewAI 这类角色制框架为什么只适合快速原型。
- 08 最佳组合：LangGraph 当骨架，Claude Agent SDK 在节点里干重活
2026 年做生产级多 Agent，别在「图框架」和「执行框架」里二选一。这篇讲清「图当骨架、节点干重活」的组合架构——LangGraph 管编排（状态/检查点/可恢复），每个节点内部用 Claude Agent SDK 的执行力（工具/hooks/MCP/子代理）干活；给你分层职责图、一段可读的组合骨架代码、逐步预期，以及一份「过度设计预警信号」清单帮你判断什么场景才真值得上这套。