--- layout: post.njk source: https://yage.ai/share/deepseek-superagent-pm-patches-20261106.html web_feed: articleId: cmw71ibgy000476ed00t9x36d feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/deepseek-superagent-pm-patches-20261106.html sourceUrl: https://yage.ai/share/deepseek-superagent-pm-patches-20261106.html speaker: yage.ai title: |- 给编程 Agent 配个项目经理：拆开 DeepSeek 常驻代理的真痛点与旧补丁 date: '2026-11-06' summary: 文章讨论了在编程 Agent 中如何为项目经理设计系统，以解决常驻代理在处理多任务和群聊讨论时的痛点。作者对比了使用复杂的状态机和数据库补丁与通过精简规则来控制模型行为的有效性。结论指出，与其用大量代码来为模型的理解力打补丁，不如通过设置清晰的四条注意力保护规则（如群聊通知限流、给机器人装熔断器、人机撞车机制、合并红线）来定义管理边界，这比沉重的状态机底座更有效。 area: tech-engineering category: ai-application tags: - agent-workflow - ai-tooling - ai-application - software-development - ai-memory people: [] companies_orgs: - DeepSeek - Claude products_models: - DeepSeek - Claude Code - Cursor - OpenCode - GPT-6 Astra media_books: [] draft: true status: evergreen --- ## 写代码不累，替五个窗口当调度员才累 目前来看，使用 Claude Code、Cursor 或者 OpenCode 来进行开发，只要是一个相对独立的 bug 修复或者接口补充，质量一般还是比较好的。真正令人头秃的情况，往往是手里同时推进几个小的开发任务。比如要频繁在第一个窗口查看测试是否已经通过，在飞书群里复制粘贴同事发的错误截图到第二个窗口，同时在第三个窗口创建一个独立分支，以便两边不会改错文件。这样虽然降低了编码的压力，但人的角色反而变成了一个全天的调度员。 日常开发中拖后腿的瓶颈，已经从怎么写对一段代码，变成了怎么给一堆并行窗口当项目经理。这和 10 月下旬我们聊的多代理组队到底买到了什么完全是两码事。那篇文章讨论的是一道单枪匹马啃不下来的复杂大题，怎么拆给几个 Agent 协同攻坚。日常研发团队面对的却是另一种麻烦：每件小事单个 Agent 都能独立干完，但几十件互不相干的零碎活儿夹杂着群聊讨论涌进来，光靠人盯着窗口建分支、传话、看进度，注意力很快就耗光了。 10 月 31 日，DeepSeek 团队开源了他们内部用的常驻代理研究原型，并发表了一篇配套设计文章。在他们的统计中，团队开发自己 Agent 框架时，超过 90% 的 PR 都是由这个系统独立提交或与工程师协作完成的。它给代码库配了一个全天在线的项目经理。项目经理在飞书群和 GitHub 里监听消息，有需求就开工单，指派后台子代理在各自独立目录里改代码、跑测试，完成后回群里交差。不过把这篇文章和 3 万行源码翻开来看，扑面而来的却是一种浓厚的上一代工程味：只要模型在一件事上犯了傻，工程师就写一套状态机和数据库表去给 AI 打补丁。它抓的多窗口调度和群聊失控确实是真痛点，但补丁叠补丁的解法却太重了。 ## 只有一个人用，项目经理手痒自己写代码到底怪谁 不妨做一个思想实验。想象一下，如果飞书群里只有你一个人类，没有同事闲聊打岔，你也只给这一个代码库派活。在这种一对一的场景下，直接开一个能调子代理的主窗口不就好了吗，为什么 DeepSeek 非要把项目经理和后台子代理拆成两层？ DeepSeek 在文章里做了一个对比实验来解释这个问题。他们写了一个脚本向系统推送几百条消息，其中既有日常闲聊也有 CI 通知，中间夹杂了 20 个修改代码的任务，专门测量调度和响应耗时。如果只开启一个普通会话且不额外提醒，模型完全不会调用子代理，所有任务都在主窗口排队，最慢的一个要等 29.5 分钟才能完成。 如果在提示词里严令它优先派给子代理、自己只做小事，大部分时候它确实乖乖派活，耗时缩短了一半多。偏偏 5 轮测试里有 1 轮，它觉得手头那个活儿不大，没忍住自己动手去跑了，结果聊天窗口当场卡死，最慢耗时又退化回了 29.0 分钟。 为了解决这个问题，DeepSeek 直接收走了项目经理写代码的工具，让它只能派工。代价是项目经理和后台子代理两边都要读上下文，多花了 3.8 倍的缓存 token，但把最慢完成时间稳定压在了 15.7 分钟。他们得出一个结论：仅用提示词很难控制住模型的手，必须用代码把它的工具给拔掉。 这话其实只说对了一半。回头看看他们那段提示词原文，里面写着一句自己只做小事。亲手在规则里给模型留了一道判断什么是小事的后门，就别怪模型钻空子下场。更深层的原因，其实是主控模型的指令遵循代差。Cohere 之前做跨模型评测时就发现，老一代或中档模型坐主控位置时，很难克制写代码的冲动，换上新一代旗舰模型才能稳定派活。 我们在日常使用公开仓库里的首席研究员与协调员工作流时，主线程用的是旗舰模型 GPT-6 Astra。规则里只有一条明确界限：主线程哪怕手里有现成的上下文，也不能把它当亲自写代码的理由，长耗时任务一律委派给后台子代理。这样一旦边界写死、不留自己做小事的口子，Astra 就能平稳当好项目经理，不会手痒下场把对话堵死。 DeepSeek 内部当然要用自家的模型当项目经理。为了对付自家模型偶尔手痒的小毛病，工程上搭了套物理围栏来补纪律：项目经理只挂只读和派单工具，派单备注不超过 30 个词，免得它越俎代庖替子代理写方案；前台命令跑满 5 秒就强制转后台，哪怕后台任务排满了，也专门给人类追问多留一个插队名额。如果在个人终端里用旗舰模型当项目经理，这套物理收权不必照抄；它解决的是一对一场景下弱主控管不住手的问题。 单人用旗舰模型配几行规则就能稳定派活，弱主控模型容易亲自下场把窗口卡死，双层架构则靠收走工具和多读 3.8 倍缓存换来不卡死。 ## 进了二十人的群聊，痛点是真的，状态机补丁却太重了 如果只是在一个人的窗口里防止模型手痒，换一个听话的旗舰模型，加上几行规则就能解决。可如果把项目经理从 1 个人的终端搬到 20 个人的飞书办公群和共享 GitHub 仓库，就会遇到三个新问题。我们在 9 月上旬讨论群聊房间的交互困境时提到，人在群里用余光扫一眼闲聊不费精力，但 Agent 即使决定忽略一条消息，也必须先把整个会话的上下文缓存读入内存。一旦群里同时推进几个工单，跟进消息会把主窗口反复唤醒烧钱，同事在评论区随口插话也可能越界加活儿，日常闲聊中机器人乱接话还会吵到所有人。 针对第一个问题，DeepSeek 引入了一个真正需要代码实现的改动：把跟进消息绕开项目经理直接扔到后台。项目经理创建工单后，系统会把最初的那条飞书话题和相关的 PR 绑在工单里。此后如果有人在这个话题或 PR 下追加评论，或者 CI 失败，系统不会惊动项目经理，而是直接把消息投递到后台子代理的收件箱。在对比实验里，这一步给项目经理带来了大约 30% 的唤醒和 27% 的缓存读取节省。这一步确实是免不掉的，因为每次惊动项目经理重读群聊缓存都是真实的 token 成本，AI 再聪明也无法绕过。 但到了后面两个麻烦，工程团队又习惯性地垒起了第二层重型补丁。为了解决同事在评论区顺手加活的场景，系统在建工单的那一刻会签发一张子代理自己改不了的授权单，上面写死了只准改哪块代码，以及建单时的权限白名单版本。后面塞进收件箱的群聊评论只能当参考看，一旦有人随口提了超出范围的新要求，比如在改按钮颜色的帖子里让人顺便重构登录接口，子代理必须调用专门工具把消息退回给项目经理重新立项；哪怕工单结案几天后有人回话想接着改，系统也会先核对当初授权单上的白名单版本，发现这人后来已移出白名单就当场拦下。 为了解决群里的噪音，他们也设计了一套严格的准入和拦截机制。系统首先会过滤掉不在白名单里的人说的任何话，然后要求模型对日常的群聊看准三件事：对方确实要求改动当前这个项目、改完之后长什么样说清楚了、没有还没拍板的设计争议。有半点模糊就闭嘴不追问。他们甚至担心机器人刚进群就开始乱接单，所以把默认档位设在观察模式，让项目经理照常可以在后台做出决策，但是在最后一步用代码拦住建单动作，只是在数据库记一笔本来想接这单的日志。 平心而论，他们找到的边界问题非常准确：群聊评论不能直接当改代码的尚方宝剑，没把握的时候宁可装死也不发消息追问人类。但解法充满了上一代传统软件工程的条件反射。因为不敢信任模型的判断力，每遇到一种越界可能就往 SQLite 里塞新表、算权限版本指纹、硬编码状态流转和代码拦截器。放到今天，如果底座跑着指令遵循能力强的旗舰模型，无论是只干当前工单范围内的活、有人提新需求就让对方另开一单，还是没点名且需求有一丝含糊就闭嘴，原本只需要在规则文件里写几行清楚的自然语言指令就能管住。用几千行状态机代码去给模型的理解力打补丁，等模型再升一代，这些重型围栏全会变成沉重的技术债。 群聊消息先经白名单与观察模式过滤，明确请求签发不可变授权单，后续跟进直达后台子代理，越界要求则退回项目经理重新立项。 ## 扔掉三万行补丁代码，今天真正能直接抄走的是四条规矩 认清了这种打补丁的思路，再去对照官方的长文和外部的宣传，就能分辨哪些是已经落地的好东西，哪些只是写在长文里的远期蓝图。比如长文里展望了一套云端容器和个人电脑后台程序的分离架构，还构想了一个监视子代理是否陷入死循环的看门狗。在公开的仓库里，这两个功能一行代码都没实现。 这个系统真正运行的环境十分简陋：一台机器上的一个 tmux 会话，数据库是一个单文件只增不减的本地 SQLite 文件，存活完全依赖每小时跑一次的检查脚本。长文说子代理不会直接跟外部对话，但是代码里子代理不仅会自己发接单确认，还会直接在 GitHub PR 的评论区回复审阅意见。项目经理和后台子代理都顶着操作员本机的完整权限裸奔。另外，前文提到的 90% PR 占比也是团队内部自报的数据，外界没办法从单次提交的开源仓库里独立核验。 恰恰因为这套系统底层就是一个单机脚本，用补丁堆叠的方式在团队中跑通了日常开发，反而揭示了一个更深层次的事实：让常驻 Agent 在研发团队里存活，并不依赖于未来可能出现的云端容器，也不依赖于那套繁琐的状态机代码，而取决于源码开篇就写下的设计哲学：占用尽可能少的人类注意力。今天我们完全可以不用部署它那套沉重的状态机底座，只需保留薄薄一层消息分流，再把他们用大量代码试出来的四条注意力保护规则直接抄进我们的轻量规则文件里。 第一条是群聊通知限流，发往聊天群的消息限制在 100 个词以内，默认只发一句话交代结果和 PR 链接，严禁汇报选了什么库、改了哪几个文件或跑了多少测试。第二条是给机器人互聊装熔断器，面对 GitHub 上的自动审阅机器人，每个 PR 最多只响应 3 轮，修好的意见直接静默关闭评论串，禁止回复已修复去制造噪音。 第三条规矩解决人机撞车，后台改代码期间一旦发现人类同事已提交解决同一问题的分支或 PR，子代理立即关掉自己的 PR 主动让路，不跟人类抢活。第四条规矩守住合并红线，只有改动少于 200 行、且最新提交拿齐所有必需审批时，才允许自动合并。上一代工程思路是拿代码和状态机给模型的短板打补丁，这一代的做法是把系统底座做薄，把真正管用的管理边界写成几行清楚的规矩。