Anthropic测试按角色拆分Agent,发现协调开销大于实际工作
Anthropic did something you'll regret ignoring:
Anthropic did something you'll regret ignoring:
Anthropic 做了一件你会后悔忽视的事情:
They split one coding task across four agents by role, as a planner, implementer, tester, and reviewer.
他们将一个编码任务按角色拆分成四个代理,分别担任规划者、实现者、测试者和审查者。
The goal was to test whether splitting agents by job title is a good way to divide the work.
目标是测试按职位拆分代理是否是划分工作的好方法。
And they found agents spent more tokens on coordination than on the work itself.
他们发现,代理在协调上花费的令牌比在实际工作上还多。
They call it the telephone game, where each handoff degrades what the next agent receives.
他们称之为“传话游戏”,每次交接都会降低下一个代理接收到的信息质量。
OpenAI and Google also built machinery for this rather than leaving it to the prompt.
OpenAI 和 Google 也为此构建了机制,而不是仅仅依赖提示词。
- OpenAI added a "handoffs" primitive to the Agents SDK - Google's ADK controls how much parent context reaches a sub-agent.
- OpenAI 在 Agents SDK 中添加了“交接”原语 - Google 的 ADK 控制父上下文有多少传递给子代理。
Both are design-time wiring. You declare which agents are reachable from which, and both ends run inside the same framework.
两者都是设计时的连接。你声明哪些代理之间可以互相访问,并且两端都在同一框架内运行。
This setup assumes you know which agent feeds which before the run starts, but plenty of agent work isn't known in advance.
这种设置假设你在运行开始前就知道哪个代理为哪个提供输入,但许多代理工作并非事先可知。
Switch, from @Flint_AI_, is built for that case. It puts agents and people in the same chat channel, so any two of them can work together without being wired to each other in advance.
来自 @Flint_AI_ 的 Switch 正是为这种情况而构建的。它将代理和人放在同一个聊天频道中,因此任意两者都可以协作,无需事先连接。
Say the error rate on a checkout service rises. An on-call agent queries the logs and finds the deploy behind it. Reading that, someone decides the next step is a chart against last week's baseline.
假设结账服务的错误率上升。一个值班代理查询日志并找到背后的部署。阅读后,有人决定下一步是绘制与上周基线的对比图表。
That decision did not exist a minute ago, so no handoff would have been declared for it. The charting agent is a separate session with an empty context window, often a different framework on a different machine.
这个决定一分钟前还不存在,因此不会有为此声明的交接。图表代理是一个独立的会话,上下文窗口为空,通常运行在不同机器上的不同框架中。
So the person makes the routing call and then moves the payload too, by reading the first agent's answer and typing a version of it into the second.
因此,人做出路由决策,然后也负责传递负载,通过阅读第一个代理的回答并将其输入到第二个代理中。
This creates three problems:
这产生了三个问题:
1) The charting agent has no record of the earlier session, so on the next incident it recomputes work the first agent already did.
1) 图表代理没有之前会话的记录,因此在下次事件中会重新计算第一个代理已经完成的工作。
2) The charting agent only sees the conclusion without the queries behind it, so it either trusts the summary or reruns the retrieval itself.
2) 图表代理只看到结论,而没有背后的查询,因此它要么信任摘要,要么自己重新运行检索。
3) When the first agent finds no regression, nobody types that anywhere, and the rest of the team never learns it was checked.
3) 当第一个代理没有发现回归时,没有人会记录这一点,团队的其他成员永远不会知道它已被检查过。
With Switch, since everyone is working in a shared channel, the person still decides what runs next, but they stop carrying the payload.
使用 Switch,由于每个人都在共享频道中工作,人仍然决定接下来运行什么,但他们不再需要传递负载。
The charting agent joins a channel that already holds the first agent's report, so it points at that report directly instead of rerunning the queries, and the next incident starts from a channel that shows the earlier one.
图表代理加入一个已经包含第一个代理报告的频道,因此它直接指向该报告,而不是重新运行查询,下一次事件则从一个显示先前事件的频道开始。
The team reads the same thread the agents do, so a no-regression result is visible the moment the first agent posts it.
团队阅读与代理相同的线程,因此第一个代理发布无回归结果时,立即可见。
Switch connects agents built with Claude Code, OpenAI Codex, OpenCode, or any HTTP/MCP-compatible framework directly to the tools your team already uses, like Slack, Teams, Discord, Telegram, and Mattermost.
Switch 将使用 Claude Code、OpenAI Codex、OpenCode 或任何 HTTP/MCP 兼容框架构建的代理,直接连接到团队已在使用的工具,如 Slack、Teams、Discord、Telegram 和 Mattermost。
Here's the repo: https://www.flintai.dev/switch-github?utm_source=X&utm_medium=influencer&utm_campaign=switch&utm_term=avi_chawla
这里是仓库链接:https://www.flintai.dev/switch-github?utm_source=X&utm_medium=influencer&utm_campaign=switch&utm_term=avi_chawla
Thanks to Flint AI team for partnering with me on this post.
感谢 Flint AI 团队与我合作撰写此帖。
更进一步:量化金融体系
看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力