评 DeepSeek Super-Agent：管好 Context 才是灵魂
内容提要
冯若航点评DeepSeek《Super-agent设计探索》：该文以Trigger+Router+Worker Session隐藏会话，解决多Agent并发管理，工程扎实但方向有误。真正难点在于管理上下文而非会话；单聊入口让Router猜测上下文易致事故，投机执行存在不可回滚的副作用。应改用群聊作为显式上下文容器，按群分级授权，指挥异构Agent舰队相互制衡；底层以共享数据库承载状态与记忆，聊天记录如WAL、Wiki如表，控制权须掌握在自己手中。
延伸解读
单聊入口的隐藏风险：Router 猜错上下文
文章指出，DeepSeek 方案用 Router 在单聊入口猜测任务归属，但 Context 是工作现场和规则边界，不应被隐藏。在能对外动手的系统中，靠猜来路由可能引发事故，例如用户说“清理临时垃圾”，Router 若误派到线上环境，后果严重。这提醒读者，评估 Agent 架构时，不能只看会话管理是否顺滑，更要看上下文边界是否显式、可审计。
群聊作为显式上下文容器：分级授权与制衡
作者主张用群聊替代单聊入口，因为每个群天然对应一个 Context，可绑定代码仓库、文档和权限。公开反馈群可允许 Agent 自动复现 Bug，而运维群则要求群、有权限的人、明确指令三者齐备才准动手。这种分级授权让安全与主动性可以并存，也便于指挥异构 Agent 舰队相互审查，而不是依赖一个全局 Router 猜谜。
投机执行的副作用不可回滚
文章批评 DeepSeek 原文中的“投机执行”：Agent 监听群聊，即使无人 @ 也后台拉代码、提 PR。作者类比 CPU 投机执行，指出 Agent 跑命令、跑 CI、提 PR 都是收不回来的外部副作用。没有显式边界，群里任何不可信的话都可能触发静默执行。读者应关注 Agent 主动性的触发条件是否明确、是否可审计，而非只看效率提升。
状态与身份：控制权能否带走
作者强调，运行环境和模型会越来越便宜、易替换，真正值钱的是状态和身份。Slack API 条款变更显示，数据名义上属于用户却可能拿不走。因此检验标准是能否带走：状态放在 PostgreSQL 里，随时可 pg_dump 迁移；放在厂商私有记忆系统中则受制于人。这为读者评估 Agent 平台提供了务实视角：入口中立、记忆自主、多模型可选，比单一厂商全家桶更可控。
Q&A
DeepSeek 的 Super-Agent 论文提出了什么架构？
论文提出用 Trigger + Router + Worker Session 的架构来隐藏会话管理：外层由事件触发器接收输入，中间由常驻 Router 判断任务该派给哪个 Worker Session，底层由多个 Worker Session 执行具体任务，Router 不亲自干活，只负责路由和汇总结果。
为什么作者认为单聊入口加 Router 猜上下文容易出事故？
因为单聊入口把 Context 也隐藏了，让 Router 去猜用户的话属于哪个工作现场。在能对外动手的系统中，靠猜来路由就是事故源头，比如用户说“清理临时垃圾”，本意是清理本地测试目录，但 Router 猜偏派错位置，可能引发线上删库。
作者主张用什么形态来管理多个 Agent 的上下文？为什么？
作者主张用群聊作为显式的 Context 容器。每个群天然对应一个工作现场，绑定了对应的代码仓库、文档和权限，用户进群开口就自动带入了正确的上下文，零成本解决了路由问题，同时还能按群分级授权、支持多对多协作。
作者如何用数据库类比来设计 Agent 的记忆系统？
作者把聊天记录比作 WAL（只追加的事实源头），把 Wiki 比作表（整理后的人可读知识），索引可随时重建。长期记忆应沉淀为文档或 Wiki，并定期整理（类似 VACUUM），记录决定和规矩，且每条结论应能链回原话。
作者认为异构 Agent 舰队应该如何协作？
作者主张让不同厂商的模型混编、互相制衡，例如 Claude 做设计规划、Codex 写代码、Gemini 和 Claude 交叉审查，通过辩论达成共识。不同模型盲点不同，交叉审查能抓出单一模型自审发现不了的问题。
作者对 Super-Agent 的底层基础设施有什么建议？
作者建议用共享数据库（如 PostgreSQL）作为状态底座，配合对象存储（如 S3），IM 只是外层皮。状态和身份必须掌握在自己手里，检验标准是能否带走（如 pg_dump）。他推崇自部署一套包含数据库、对象存储、IM 和常驻 Agent 的环境。
