我的新职业，agent 的包工头

前几天，我在工作区的聊天框里敲了一句很随意的话，让北极星去把产品经理和架构师拉上，就当前原型和代码实现之间的差异开一次专项会，开完给我一份能往下走的方案。

我没定时间，没写议程，也没建群。发完就切去干别的了。

等我回来，这件事已经长出了一个我能看懂的样子。会拆成了三段，参会的人定了，产出也定了，连会后要交什么都写好了。

那一刻我大概认清了自己换了个什么身份。我不得不把自己那点搬砖天赋留在昨天，然后去当一个 agent 的包工头。

图 1 我在聊天里让北极星去拉会，它自己拆出了议题和产出

我派下去的第一件活，是一场会

北极星没有立刻动手，它先把会拆成三段。差异分析，把当前实现和设计原型逐项比对。技术评估，找出每个差异背后的技术原因，判断现有代码哪些能复用、哪些必须改。方案制定，围绕让最终产品更贴近已经认可的那版原型这个目标，给出可执行的路径，连同资源和时间估算。

然后它把活分给两个人。产品经理负责视觉、交互和认知层面的比对，架构师负责偏差根因和技术可行性，它自己做主持和最终文档。

它还写清楚了一件事，会开完要输出正式的会议纪要和解决方案文档，两个参会方都得对结论形成共识，后续动作要有明确方向。

看到这里我的第一反应是，这段话平时是我在周会上说的。现在我坐在屏幕这头，只发出一句需求，剩下的排期、分工和交付标准，由我的包工头替我讲。

一张会，开成了五张卡

再刷新一次，任务看板已经动起来了。

图 2 一张会议被拆成五张任务卡，分派到三个智能体名下

看板从左到右是待规划、待办、进行中、审核中、已阻塞、已完成。我截这张图的时候，待办里躺着两张卡，都是 Stage 2 统一方案 v0.1 的交叉评审，一张挂在架构师名下，一张挂在产品经理名下。进行中那张是北极星自己主持的差异审查与架构方案，进度显示 2 比 4。已经完成的两张，一张是产品经理交的原型视觉与交互差异审查，一张是架构师交的偏差根因与 DSH 复用性评估。

右上角写着三个智能体正在工作。

我没有点开任何一张卡，也没有催。分工、依赖和先后顺序都是北极星排的。当包工头的好处就在这里，活派下去以后，谁在等谁、谁先交，看板自己会说话。

需要人拍板的活，它会发邮件

我决定把这件事写下来，起因是邮件。

图 3 需要人拍板的环节，它会把材料整理好发到我的邮箱

智能体干完一轮活，如果结论需要人来认，它会整理好材料发一封邮件给我。收件箱里那一排是同一个项目的几场会，三条状态是审核中，两条已完成，一条已取消。取消的那条是早先的投标评审整合计划，被新的讨论取代了。

邮件正文里有一段固定评估基准，值得单独看。它把这次讨论的前提锁死了。已经认可的那版原型是唯一的验收基准，不重新设计，也不拿旧的需求文档去覆盖它。产品侧和 DSH 侧的代码各自固定在一个提交号上，免得讨论过程中代码又往前跑。原先必须基于上游设计开发的约束先解除，允许提重构方案。现在这版实现里技术上的那些妥协，只能算待证假设，要用代码和运行证据去核实。它还额外声明了一条，检查过程不覆盖我的工作区。

这几句话都在处理同一个麻烦。让智能体讨论技术方案，最怕它们在空气里辩论。把基准、提交号、证据要求和边界一次写死，讨论才有落点。

包工头最担心的就是底下人自己改方案。这份基准相当于每次动手前先对一遍的规矩，对完再干活，后面验收才有依据。

我问了一句进度，它把文档和判断一起交上来

中途产品经理那个运行时挂过一次。我后来在聊天里问进度，北极星先说起这件事，又告诉我它已经恢复并补交，只是流程停在了等待两方验收的状态，它已经重新触发。

图 4 随手问一句进度，它把两份文档和下一步判断一起给我

这一次它把两份文档的 v1.0 直接附在了消息下面，一份会议纪要，一份解决方案与行动计划。然后它做了一件我认为最关键的事，它没有往下走。

它给的建议是这样的。先做 WO 的可行性验证，总投入上限控制在两到三人日。多附件那条目标先保留，报价自动化先评估再估算，不默认缩减原型范围。本期内已经验收的浅色原型继续有效，不新开暗色设计的范围。带存疑的结项报告先内部复核，不自动对外发布。

最后它说明了为什么停下来。我最初授权的是专项讨论和方案制定，启动 WO 验证会进入新的实施验证阶段，这个决定得我来做。

这一下我心里挺舒服的。它把包工头该做的事情都做了，然后老老实实把最后那个决定留给我。

我手底下的七个 agent

说到这里，得介绍一下这个工作区里到底住着些什么。

图 5 七个智能体，各自的运行时、建议模型和职责

它们的协作关系大概是这样。

你（人类 Owner）
   │ 提出目标
   ▼
【北极星 · Chief of Staff】
   │ 拆解任务、协调智能体、跟踪进度
   ├───────────────┬────────────────┬────────────────┐
   ▼               ▼                ▼                ▼
【产品经理】     【架构师】      【程序员 1/2 号】   【搬砖牛马】
产 PRD 与高保真   系统设计与 CR    写代码、改 Bug     调研、知识库、文档
原型与验收标准    接口与数据模型   维护版本           并行提供信息输入
   │               │                │
   └───────────────┴────────────────┘
                   │ 代码提交
                   ▼
             【OPS 运维助手】
             Git 操作 / 发布 / 日志 / 线上定位
                   │
                   ▼
              【北极星】汇总结果
                   │
                   ▼
                 交付给你

一句话概括，北极星驱动，产品定方向，架构定骨架，程序员搞实现，牛马供弹药，OPS 管上线。

这里有个词得解释一下。搬砖牛马不是我嘴欠，它就是团队里那个到处找材料、写初稿、把信息喂给别人的角色。我以前干的很多活，现在归它。

权限边界比职责写得更细

搭这套东西的时候，我一开始也想只写职责。后来发现右边那一列权限边界，反倒决定了它能不能用起来。

产品经理不写业务代码，也不干涉底层架构。架构师不接日常编码，也不决定产品优先级。程序员 2 号跑得快，代价是容易在细节上想当然，所以它的产出必须由 1 号或者架构师看过。搬砖牛马负责到处找信息和写初稿，但最终判断不归它。OPS 手上是发布、改配置、定位线上问题这类高危动作，所以它不碰业务逻辑，真出格的操作要人来点头。

为什么这么在意这条边界。因为智能体之间不会累，不会烦，也不会有人的那点体面顾虑。一个没有边界的智能体，会把别人的活顺手干了，而且干得看起来挺像样。等你在评审时发现架构已经被改了一半，成本已经付出去了。

越界比慢更贵。这套边界帮我省下的，正好是最容易白花的那部分时间。

运行时和模型的搭配也是混着来的。需要判断的地方交给 Codex 配 GPT-6 Astra，关键 CR 切到超高。需要快速铺量的活交给 Pi 配 DeepSeek V4.1 Flash。最重的信息收集丢给 GPT-5.6 Luna 的最高档。同一条流水线上放不同家的模型，某个模型犯轴的时候，整条线不至于一起停。

我也翻过车

早期我让北极星自主推进，它就真的一路往下推。产品经理和架构师各自的意见写进纪要以后，纪要里出现了三方已经达成共识这种话，可实际上谁也没有点头。方案里的估算日期，也被当成已经承诺的排期往下传。

后来我在流程里加了几条。

交叉评审必须留下实际的往返记录，任何一方不得代替对方宣称同意。方案里必须写清负责人、依赖、人日区间、资源假设、关键路径和预计日期，日期如果是估的就标明是估的。要进入开发，先建 backlog，不擅自开始。每个阶段的产出通过任务附件交付，父任务里留结果摘要和证据索引。

加上这几条以后，图 3 那封邮件里的东西才有意义。它交上来的东西能被人查证，不再只是一段听起来很对的结论。

现在回看，那次翻车暴露的是包工头最容易犯的错。我图省事，把判断权也一起派出去了。底下人自己拍板，活是往前走得快，等你发现方向不对，人日已经花掉了。

包工头最后剩下的活，是做决定

这七个智能体不太像我原来想象的助手。它们更像一支能干活的外包队，有人在开会，有人在写文档，有人在跑验证，而我的工作从自己动手变成了派活、跟进和做决定。

这个变化有好有坏。好消息是那些我本来要自己组织的会议、自己整理的对比清单、自己追的排期，现在有人替我往前推。坏消息是我的判断变得更贵了。图 4 里那份建议摆在我面前的时候，停下来等我点头的那一句，是整条流程里唯一不能外包的部分。

自己动手的日子结束了，听起来有点可惜。可我现在每天干的活，是盯着七个人别干错活，然后在该做决定的地方做决定。这活也不轻松，只是换了一种累法。

如果你也在搭类似的东西，我的建议是先写清楚谁不能做什么，再写谁做什么。前者看起来像废话，实际决定你半夜会不会被一个自作主张的架构变更吵醒。