--- layout: post.njk source: https://yage.ai/share/babysit-agents-management-not-context-20260826.html speaker: yage.ai title: |- 为什么你停不下来 babysit agents：不是 context 的问题，是管理的问题 date: '2026-08-26' summary: 文章探讨了在管理AI Agent时，核心问题不在于上下文窗口大小，而在于任务管理和流程设计。作者强调，真正的解法在于减少无谓的消耗，通过让模型进行静态预测、锁定任务目标和确保运行结果可见性，来缩短单轮探索长度，从而避免频繁重开会话。最终建议将精力从上下文维护转移到前置的管理动作上，如清晰的交付边界、动态反馈机制和明确的验收标准，以实现Agent的自主闭环。 area: PAI category: ai-workflow tags: - agent-management - context-optimization - workflow-tools - task-goal-locking - feedback-loop people: [] companies_orgs: [] products_models: [] media_books: [] draft: true status: evergreen --- 社区里有位朋友，既要带团队又要写核心代码。每天日程排满了各种会议，只能在开会的缝隙里抓紧写上几行。前阵子他跟我们聊起近况，说自己没法把整个项目交给 agents，大半精力全花在 babysit agents 上面。1M 的 context window 跑不了多久就超出 30%-40% 的最佳区间，只能反复让 agent 总结没做完的任务，接着开个新 session 继续顶上。一整天盯着刷屏的信息流，到了下午四点左右脑壳就开始发胀。他的动手能力很强，摸索也走在很多人前面，不仅把遇到的问题摸得清清楚楚，还自己拉出了整套归因和排查清单。连这样的高手都会陷进去，说明这个问题太典型了。 为了解决这个问题，他先把大家能想到的常规手段全试了一遍。先做上下文瘦身，清理 AGENTS.md 和 CLAUDE.md，删掉模型升级后残留的旧 prompt，卸掉平时用不上的 MCP 和 skills。我们在 Thin Harness, Fat Skills 里详细聊过这套思路。接着他又搭了一套编排工具，让主 agent 通过 tmux 同时调度多个 session。即便做到这个地步，主 agent 的上下文依然迅速见底，到头来还是得靠人工频繁新开会话去接力。讨论的完整记录在这里，Superlinear Academy 会员可以直接看当时的对话。 读到这里你可能会问：大家都在为 context 发愁，凭什么说它只是表象？其实 context window 本质上是一笔预算。agent 每读一个文件、每试跑一次、每撞一次墙，以及我们每次插手纠偏并重新注入背景和状态，都在消耗这笔预算。消耗速度有多快，取决于每一轮探索有多长。如果 agent 目标明确、能看清自己的运行结果、能拿到即时反馈，单轮探索就会很短，很快就能收敛，窗口也就填得慢；要是缺了这三样，它在每一轮里都会四处绕路，窗口转眼就见底。所以窗口填满的速度，只是任务管理好坏的仪表盘读数，本身并不是病根。证据就在这位朋友的经历里：反复开新 session，无非是把仪表盘一次次拨回零刻度，只要 agent 还在原地打转，读数依然会飞快飙升，归零仪表盘并没有改变花钱的根源。 所以真正的解法，既不在于把 1M 窗口继续做大，也不在于更频繁地重开会话，关键是要减少无谓的消耗。清理 prompt 和精简上下文确实有效，但解决的只是最后一英里的收尾工作。如果不去解决前面的管理问题，agent 还在频繁绕路、到处试探、接连碰壁，逼得人不得不一遍遍插手纠偏。上下文塞满只是最后冒出来的症状，根子全在更前置的三项管理动作上：让模型去做静态预测、任务目标没有锁死、模型自己看不到运行结果。我们一个一个过。 上下文维护是最后一英里的收尾动作，管理动作才是第一步 ## 你以为是 context 问题，其实是管理问题 大家习惯把力气花在上下文维护上，这种直觉特别好理解。窗口确实会填满，顺手清理一下 prompt、做做压缩或者开个新 session，往往立马就能让卡顿的体感好转。但这些动作只管得了一时。重开和清理只是把消耗的读数抹平，只要干活和花钱的方式没变，跑不了多久上下文照样会迅速见底。想把无谓的消耗真正降下来，关键得换个视角，看看我们平时是怎么给它派活的。 想理顺这套逻辑，有个直观的参照：把 agent 当成团队里新来的工程师。平时你希望老板怎么给你交待任务，你就怎么给 agent 提要求。靠谱的交接从不会只扔下一句你把这个搞定就甩手不管，总要讲清楚交付什么、边界在哪、怎么才算做完。给 agent 分配工作，道理完全相通。 接回开头的预算框架来看，静态预测、目标没锁、结果不可见这三个管理缺口，正是无谓花钱的三个地方。让 agent 静态预测，它拿不到及时反馈，只能读更多代码到处硬猜，搜索空间怎么也缩不小；目标没锁，它每轮都要重新琢磨你到底要什么；它看不到自己的运行结果，遇到问题只能跑来问你，人就成了反馈回路。管住这三样，就是在直接缩短每一轮探索的长度。这位朋友在 context 侧做的两个实验，恰恰把症结逼了出来。他给 agent 写 prompt 时手打了五条背景，其中四条一字不差就躺在他自己的 wiki 里，这套 wiki 是他搭的 observation agent 每天自动沉淀出来的。管理动作他一样没落下，可他拿真实 prompt 去查，发现主 agent 翻不出 wiki 里的东西，每次还是得事无巨细重新交代一遍；前面讲到的 tmux 编排实验也是同样的结果，主 agent 的窗口照样迅速见底。做了管理和让管理起作用之间，差的不是模型，是把回路闭上这一环。这一环还是管理动作，补不上它，人还是得跟在后面操心。 反过来，只要管理动作到位，效果就大不一样。他在项目做到一半停下来，重新定义了 goal 和验证方式，之后 agent 回头自己去写测试，自主性明显提了上来，这一步的细节我们后面会展开。我们自己也有过一样的经历：前段时间做一个复杂的社区后台，前期探索非常 overwhelming，跟 AI 对话只会发现更多问题，花了好几天才把设计定型；设计一定型，下面就简单了，设一个明确的 goal 让 AI 自己跑，两三天就做出来了。这些虽然都是真实的案例观察，没有做严格的受控实验，但方向是一致的：发生改变的都是管理动作，模型还是原来的模型。 在沉淀 context 这件事上，这位朋友下的功夫其实很深，手头同时跑着两套系统。一套是他自己搭建的 observation agent，每天自动抓取 session 里的技术细节，沉淀出了 18 页 wiki 和 1418 行 index。他在采集端做得非常扎实，可惜主 agent 平时从不去查，路由上少了一点拨。另一套是 harness 自带的 memory，按工作目录各自切片，机器上 22 个 store 各管各的，跨仓的知识没有安放的去处；后来尝试把工作区设到父目录统一管理，结果父目录的 store 几乎是空的。后来他主动调整策略，把核心知识收拢到自己的代码仓库里，只把 harness 里的记忆作为检索指针。这套方案我们在 context infrastructure 开源仓库里放出了公开版本，AI Builders 的 Module 2 和 Module 3 也梳理过私有上下文的组织方式与人机分工边界。如果想看团队场景下的做法，可以参考团队中共享 AI skills 的原则与方法。打理上下文属于打基础的工作，但要想摆脱 babysit，关键还要靠更前面的管理动作。 一句话核心判断：babysit 的根源在管理流程，不在模型能力；做好 context 维护只是打扫战场，解决不了源头问题。 ## 别让它静态预测，给它动态反馈 很多团队的云原生环境和 CI/CD 流水线里，都藏着大量只有踩过才知道的暗坑。这位朋友最开始把代码库全量开放给 agent，代码都在那儿，按理它光看现有配置就能把潜在问题全扫出来。大家刚开始用的时候往往也是这种第一反应，但这其实默认了模型拥有超常的静态推演能力。 真人排查这种故障，通常也要靠反复提交构建、看报错日志、对照源码，一点点把坑踩明白。AI 的学习路径也是一样的，同样需要经历撞墙、拿到反馈、分析归因，才能建立起靠谱的认知。只让它干看代码就凭空猜出各种异常场景，往往超出了模型的能力范围。退一步说，哪怕未来模型推理能力更强了，这种硬猜的方式我们也不推荐。我们写代码都有体会：干瞪着屏幕找 bug，远不如挂上调试器、跑个测试用例把问题逼出来轻松。只要有条件做动态验证，就别让 agent 闷头做纯静态预测。 更接地气的做法，是顺着具体任务帮它搭起正向反馈。先让 AI 去读历史的 CI/CD 失败日志，对照源码把每次出错的原因弄明白，再把踩坑记录、背后机理和解法沉淀成文档。落到实际操作上，有两个容易掉坑的地方，需要搭配对应的管理手段。 第一个坎是它容易把规范抛在脑后。文档写好之后，主 agent 转头可能就忘了看。这时候需要通过静态注入或者交互提示把它拉回来。如果用 Claude Code，可以在根目录的 CLAUDE.md 里加一条规则，提醒它排查 CI/CD 问题时先看指定目录的避坑文档；或者在每次布置任务时，顺手带上一行提示，让它对着现成文件展开排查。 第二个坎是上下文容易塞爆。面对几百条构建日志，单个 agent 很容易在海量信息里迷失，跟狗熊掰棒子似的，看到后面就把前面的东西丢了。更可靠的办法是开并发子任务，让每个 sub-agent 分工精读比如 10 个 job，把提炼出的经验写成简报，最后再由主 agent 统一汇总。Claude Code 的 dynamic workflow 就很适合干这个，能自动编排调用链路，让多个 sub-agent 各自提炼再汇总结果。 教训从撞墙到日志到文档逐级蒸馏，主代理只读汇总结果 这跟现实中带实习生完全是一个道理。带新人联调流水线，除了给看代码，你还会给他配上测试工具；让他把踩过的坑写成工作手册；平时时不时提醒一句，让他按规范执行；如果手头活实在太多，就安排秘书团分头处理，或者写个脚本跑批处理，帮他把脑子腾出来。 一句话核心判断：agent 搞不定没有测试过的暗坑；给它动态反馈并沉淀 SOP，远比直接甩给它一堆权限管用得多。 ## 你自己都没想清楚，它猜什么 很多时候活干不完，问题出在需求边界没划清楚。要是你自己都不知道最终要什么，agent 就只能在那瞎猜。这就像产品经理甩过来一份粗糙的需求，中途天天推倒重来，开发团队不仅干得难受，效率也会直接垮掉。 有人可能会犯嘀咕：如果每一步都要人先想得一清二楚，还要 AI 干什么？其实 agent 不光能跑腿写代码，还能帮我们理清架构思路。拿这位朋友把黑客松原型迁移到 Kubernetes 集群的经历来说，整个协作大致分成了三步。 第一步，让 agent 摸清现有代码，并给它相应权限去真实调用服务。它可以通过 Slack API 或者浏览器自动化来模拟用户操作，直接在真实环境里跑通逻辑。这一步的目标是产出两份文档：一份定义行为的 PRD，一份决定设计的 RFC。AI 写出来的文档往往又臭又长，硬着头皮通读太耗精力。你可以明确要求它以低认知负荷的形式汇报，直接列出核心结论、潜在风险和需要你拍板的关键项。甚至可以让它顺手生成一个带图表和卡片的轻量网页，直观呈现系统状态。每个人习惯的信息密度不一样，让 agent 配合你的阅读习惯，本来就是它的强项。 第二步，拿着前面理出的文档做定向沟通。你可以从一句明确的目标开始：把这个黑客松原型改造成生产级服务并部署上线。接着跟 agent 一起讨论取舍，砍掉哪些多余功能、保留哪些核心逻辑、加上哪些安全边界，再把这些讨论落成具体的技术决策。你甚至可以把喜欢的汇报格式写成一份固定文档，以后直接让 agent 照着做。cognitive bandwidth 是你最稀缺的资源，没必要逼自己去啃冗长晦涩的文字，多让工具来适应你的节奏。 第三步，定死最终的验收标准。要是只停留在前两步，整个流程依然是个开环：agent 说自己做完了，你还得四处核对排查，反倒成了给它跑腿的人。拉起闭环的关键，在于把成功状态定义得清清楚楚：哪些功能不可妥协，哪些坏味道坚决不能有。抓住核心链路并覆盖关键场景，只要这些硬指标全跑通，你就有八九成把握东西能用。把标准定死之后，agent 就能在你睡觉时全天候自主试错，靠密集的报错反馈迅速收敛问题。 第二轮讨论还逼出了一个关键细节：临时做的可视化网页和正式文档到底是什么关系。AI 生成的图表网页只是个临时视图，用来帮你快速看懂和拍板；真正可靠的单一事实来源，依然是那份严谨的 Markdown 文档，讨论中敲定的修改必须同步写回文档里。 还有一个更关键的管理习惯：手里要有一份简明扼要的需求底稿。AI 写出的长篇大论通常没人逐行细看，里面塞满了各种想当然的默认配置。如果不把这些没验证过的细节清理掉，agent 后面写代码就会不断给自己加戏，加进一堆多余的限制，代码不知不觉就跑偏了。这位朋友在项目做到一半时，主动停下来重新对齐目标，把原先臃肿模糊的说明收拢成两层清晰的目标。很多项目之所以烂尾，就是因为没人愿意停下来重新校准方向。我们需要亲自审定一份极简文档，只写死不可碰触的底线原则，给后面的实现划好红线。 这跟当主管带团队是一样的。管理者不用去啃下属写的每一页草稿，下属负责把关键信息提炼清楚来汇报，主管负责权衡取舍、把控安全底线、纠正方向偏差，搭起一套不用时刻盯梢也能自己跑顺的闭环机制。 一句话核心判断：目标悬而未决时，agent 的每一次偏航都在消耗你的 context；一份亲自审定的极简需求，胜过十轮发散的头脑风暴。 ## 它看不到自己的结果，就永远在开环 高效协作的核心在于杠杆：花 5% 的精力拿到 100% 想要的结果。这 5% 真正花在刀刃上的动作，就是让干活的人清楚知道进展顺不顺利、有没有做对。定好交付边界很重要，但还有个前提同样不能少：给了验收标准之后，agent 手里有没有工具去验证自己的活干得怎么样。 要是 agent 连看 CI/CD 日志的权限都没有，就拿不到详细的报错堆栈。这时候哪怕你催它把构建跑通，它对着红红绿绿的状态图标也摸不着头脑，没办法自己顺着线索去改错。 开环里人沦为瓶颈，闭环里人只做验收 所以在动手之前，先要把路上的绊脚石扫清，算清楚模型自己验证时需要哪些权限和接口。要是出于安全考虑不能直接给线上环境，可以搭一个高度仿真的沙箱给它折腾。给 agent 一个安全又真实的操作空间，让它能凭着客观指标看懂任务状态，拿到详细的报错信息来对齐差距。 在推进项目时，这位朋友也碰到了几处必须人工介入的卡点：代码合并要别人审批、数据库权限要找专人开通、GitHub App 得手动安装、Slack bot 的 token 要存进 1Password。他在项目做到一半时敏锐地抓住了这些阻碍，把目标和检验手段理顺，列出了一份专门由人工操作的待办清单，把这些环节单独隔离出来。很多人直到项目做完都没意识到这一层。把自动化和人工干预的分工界限划清楚，省去了假装全自动带来的脱节，agent 的自主闭环才能顺畅运转起来。 一句话核心判断：验收标准给出了目标，结果可见性带来了自检能力；没有及时的反馈通道，人就只能沦为到处跑腿的检查员。 ## AI 放大杠杆，也放大负担 整个项目最终花了 2 周时间顺利上线，全程都是抽开会的缝隙，外加一个晚上的加班搞定的。面对高密度的信息吞吐，这位朋友坦言脑子确实累得不行，甚至一度怀疑是不是用 AI 反倒加重了负担。 其实这种心智消耗在以前自己写代码时也一样存在。需求推导、架构取舍、边界验证，这些费脑子的事一件也少不了，只是以前开发周期拉得很长，时间把思考压力给摊薄了。现在 AI 既能当工程师又能当架构师，还能兼职秘书，把整个开发周期压缩了一大截。它成倍放大了产出效率，也把高密度的思考负荷一下子堆到了面前。能不能适应并驾驭这种高频协作的节奏，正是 AI 人才竞争的一个方向。 如果放到团队层面看，搭沙箱机制是个特别务实的切入点。现在转型 AI native 是个近似政治正确的说法，每个老板都想要，但很多时候面对的是脏活累活，卡在组织架构的改变上。给 agent 搭一套好用的运行环境和安全沙箱，是纯粹的工程技术活。它不用动组织架构，也不用改现有的绩效分配，做起来阻力小，又能实实在在地解决问题。具体怎么落地，可以根据各个团队的情况因地制宜。 回到最开始的问题：怎样才能让 agent 真正独立干活，把我们从没完没了的盯梢里解脱出来？关键就在这三件事：提供动态测试环境，让它通过报错把踩坑经验沉淀成工作手册；把交付边界界定清楚，用一份亲自过目的人工极简需求把好关；打通运行结果的可见性，让开环的人工核对变成闭环的自主校验。这套思路跟带初级工程师完全相通。当敲代码的基础能力越来越普及，怎么把任务交代清楚、怎么划定边界、怎么做好验收，反倒成了拉开身位最重要的真本事。 一句话核心判断：摆脱没完没了的盯梢，关键在于把自己从一线执行者转变为出题和定规矩的人，别总想着换个更聪明的模型来解决问题。