多智能体协作最终都绕不开工单追踪
Every multi-agent setup ends up reinventing a ticket tracker.
作者认为,每个多智能体(multi-agent)配置最终都会重新发明一套工单追踪系统;而他自己的方案是直接把追踪表放进 Notion。被引用的帖子进一步说明:他用 Notion 作为云端智能体的记录表,每个 PR 一行,记录负责的智能体、CI 状态和下一步,智能体开工前先查表,从而避免两个智能体修同一个 bug。
查看原帖我用 Notion 作为我的 @bot 云端智能体的记录表。 我有一个 bot,它会接收我所有的 PR 工作,并分派给云端智能体。 当多个智能体同时运行时,问题就不再是代码本身了。而是要清楚哪些任务正在进行、由谁负责、哪些卡住了以及为什么卡住。 聊天记录在这方面很糟糕,非常糟糕。它很长,会滚走,而且每个 bot 和智能体都有自己的一份。 所以一切都放进一张表里: > 每个 PR 一行 > 工作一开始就立即创建行 > 记录负责的云端智能体、CI 状态、下一步 > 智能体在开始前先查表 > 问“那个 PR 在哪?”只需读那一行 > 每天对照真实 PR 做一次巡检 > 已完成的行隐藏,但从不删除 结果是,没有两个智能体会修同一个 bug,而且我可以询问任何 PR 并得到直接的回答。 到目前为止,它只丢了 11 个 PR,而那些 PR 从未有过对应的行…… 关于这套设置的更多内容,很快奉上 ✌️
查看原文
I use Notion as a ledger for my @bot cloud agents. I have a bot that takes in all my PR work and hands it out to cloud agents. With several running at once, the problem stops being code. It's knowing what's in flight, who owns it, and what's stuck and why. Chat history is bad at that, really bad. It's long, it scrolls away, and every bot and agent has its own. So everything goes in one table: > one row per PR > row is created immediately when work starts > store owner cloud agent, CI status, next step > agents check the table before starting > asking "where's that PR?" just reads the row > daily sweep against the real PRs > done rows hidden, never deleted The result is that no two agents fix the same bug, and I can ask about any PR and get a straight answer. So far it's only lost 11 PRs, and those never got a row... More on this setup soon ✌️
正文
Every multi-agent setup ends up reinventing a ticket tracker.
Mine just went straight to Notion.