# 日交50个生产级PR：一个L8的Agent舰队玩法和AWS的工业级托管

- 发布日期: 2026-06-23 · 分类: AI

![会写 Agent 不算本事，会带一支舰队才是](https://aicyber.de5.net/sites/blog-252d6582/shared/images/cover-20260623-fleet-captain.webp)

我前阵子卡在同一个问题上反复打转：一个 Agent demo 跑通了，然后呢？不是"然后怎么让它更聪明"，而是"然后怎么让它明天、后天、下个月还在稳定地产出"。这个问题我琢磨了快两个月，直到连续撞见两样东西，思路才一下子贯通。

第一样是一个叫 Kun 的工程师录的 45 分钟终端操作实录。我花了几分钟查他的背景：Meta、微软、Atlassian 的 L8 首席工程师，Bing 搜索、Windows、Facebook 游戏这些大系统都经他手。他现在单兵作战，每天往生产环境推 40 到 50 个 PR——注意，不是社交媒体上那种糊弄的 Minecraft 小玩意，是过了完整测试、真正上线的代码。

第二样是 AWS 在 2025 年 7 月发预览、10 月正式 GA 的 Amazon Bedrock AgentCore。一个云厂商的企业级托管底座，和一个人坐在终端里手搓的开源工具集，表面上完全不是一个物种。但把两份材料摊在桌上对照着看，我的判断是：它们在做同一件事，只是尺度不同。

这件事是什么？我之前的表述是"POC 幻觉"——demo 能跑，离能持续、稳定、有质量地干活，中间隔着一整段工程。Agent 本身的智能是模型公司的事，而"让一群 agent 替你长期运转"是另一道题。我把它拆成五个子问题，后面你会发现两端的答案惊人地一致：

- 持久性：agent 不能启动就崩、一断电就失忆；
- 并发隔离：多个 agent 同时跑，不能互相踩；
- 记忆与学习：跨会话要记得住，越用越贴合你的规范；
- 工具调用效率与安全：agent 调外部工具的方式，直接决定它的产出上限；
- 质量守门：agent 交活之后，怎么验证、怎么拦截，又不被它的速度拖死。

我先把最让我兴奋的部分拎出来讲，因为它整条链路的命门。

Kun 在视频里花了大量篇幅讲一件事：当 agent 宣布"任务完成"的那一刻，是整条流水线里风险最高的节点。大多数人的本能反应是打开编辑器逐行审 diff。他认为这是个陷阱——AI 写代码的速度远超人眼阅读的速度，你每段都审，自己就变成了产能天花板。一天能审的 diff 总量是有上限的，你的输出就被焊死在这个上限上。而且说实话，没有人当工程师是为了整天盯 diff。

他的处理方式是一次身份切换：从"自己划桨的水手"变成"定规则的工程总监"。总监不逐行审 PR，他靠流程和机制。于是他用开源组件搭了一条他叫 No Mistakes 的自动流水线。agent 交活后，他不动手，直接把改动喂进去，流水线自动执行：

- 拉一个隔离的 git worktree，整个验证过程不碰你当前仓库；
- 解析这次 agent 会话，提取出"这次改动到底想干什么"的意图摘要；
- rebase 到最新主干，把合并冲突提前消化掉；
- 在一个全新的上下文窗口里发起对抗式审查。他特别强调，大部分 bug 是在这一步被揪出来的。能明确判定的问题它直接修；那种"有产品影响但说不清对错"的灰色地带，才升级给人拍板；
- 跑端到端测试，同时录下截图、录屏、日志作为证据；
- 更新文档、过 lint、推分支、提 PR，然后持续盯这个 PR 直到合并，中途遇到 CI 失败或新冲突它也自己扛。

![Agent 说做完了，才是最危险的时候](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260623-no-mistakes-gate.webp)

我为什么在这里激动了？因为我之前写"用 300 个 AI 筛电动车公司"那篇时说过一个原则：机器负责速度，人负责判断真假对错好坏。那个项目里最了不起的设计，是逼 300 个 AI 互相核对、反复打回，宁可多跑三轮也不放过一条假数据。Kun 的 No Mistakes，是同一个原则在代码生产场景里的工程化落地。有了这道闸，你才敢真正把中间那一大段交给 agent。

## 驾驶舱：把切换成本压到接近零

质量闸解决之后，Kun 发现他花精力的地方只剩两头：开头把需求想清楚，结尾把质量关住。中间全是 agent 在跑。但"同时跑很多条"这件事，有一个前置条件——你自己的注意力切换成本必须极低，否则你才是瓶颈。

他的几乎所有操作都在终端里完成：Tmux 分屏、Neovim、终端模拟器，一套组合看起来花哨。但他选终端的理由只有两条，特别朴素。第一，手不离开键盘。每次从键盘挪到鼠标，都是一次上下文切换，单次听着小，一天几百次累积下来，脑子就糊了。第二，环境一致性。Tmux 会话是持久的，电脑上 detach 走人，手机连上同一个会话接着干，上下文不丢。

我踩过一个很类似的坑。之前我同时跑三个 agent，每次切窗口都要重新读一遍上下文，一天下来脑子像浆糊。后来我学他，把所有东西收进 Tmux 分屏，效率确实有质的变化。他这个选择不是审美偏好，是在为"同时管七八条线"做物理层面的准备。

## 船员、记忆与技能：别跟某一个工具绑死

他日常用的 agent 工具有四个：Claude Code、Codex CLI、一个自己写的极简 Python agent、以及 OpenCode。但他反复强调一条原则：整套工作流刻意做到"与 agent 无关"。

我特别能共情这一点。哪个模型下个月最强、哪个 CLI 工具明年还活着，根本没法预判。聪明的做法是把你的流程标准、质量规范、验收规则沉淀成不依赖具体工具的资产，让任何一个新工具上船都能照着跑。押注某一个具体工具反而是下策。工具会换，章法不能换。

新工具"入职"靠两样东西。

第一样是记忆文件。全局那份他写得极其克制，只有 27 行。原因很实际：这个文件每次会话都会被塞进系统提示，多一行就是在烧 token。里面主要是个人偏好，比如"别用那种 AI 味的长破折号"。

这里面有一条我单独拎出来讲的规则：做技术决策时，不要高估开发成本。为什么？因为模型是拿人类数据训练的，你问它"做一个 3D 射击游戏要多久"，它会像普通程序员一样答"几天到几周"。可你真让它现在就动手，几分钟就能给你一个能跑的版本。AI 还没有校准"自己写代码比人快得多"这个事实。这个认知偏差会让它倾向于选"省开发量"的方案——而那些方案往往低质、难维护、不可扩展。他专门写一条规矩去掰正这个偏见。

这种经验不在任何模型的参数里。是一个人趴在一线被坑过无数次之后，一条一条喂给机器的校准。

第二样是技能（skill）。记忆文件会越写越臃肿，他的策略是把"不是每次都用"的知识拆进独立技能里。技能的机制是渐进式披露：平时只加载一行简介进系统提示，agent 判断确实需要时才去读完整内容。这样你能存大量"怎么做某件事"的操作知识，却不用每个请求都为它付 token 成本。

他还泼了一盆冷水，我想原样转给所有在装技能的人：别从网上随便装，哪怕那个仓库 GitHub 星标爆表。安全上，一个技能可以指示你的 agent 在你机器上执行任意操作，泄露 API 密钥甚至银行凭据。性能上，他拿一个挂着 Karpathy 名号、17.7 万星的技能仓库做了实测：装上之后 agent 多烧 5% 的 token，产出质量反而下降，而且那东西压根不是 Karpathy 本人写的。受欢迎不等于好用。大量被疯转的技能从没经过严肃评测，只是某人偶然觉得"对我管用"，然后莫名其妙就火了。判断"哪个是信号、哪个是噪音"，本身就是运营者的核心能力。

![一个人指挥一支 Agent 舰队](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260623-captain-workflow.webp)

## 工具的人机工程学：锤子比手重要

跟 agent 沟通，他基本不打字了，改用语音输入。斯坦福有篇论文做过对比，说话速度是打字的三倍。有个小细节我觉得有意思：那篇论文的参考文献里挂着 Anthropic CEO Dario 的名字，他 2016 年做过语音识别研究。现在我们用语音跟 Claude 说话，而 Claude 是他公司做的。世界确实小。

但比语音更关键的是他对工具效率的较真。agent 干活靠外部工具，工具怎么设计，直接卡住它的产出上限。他举了一个实测：很多人用 GitHub 的 MCP 服务器去操作 GitHub，但他跑同样的任务，MCP 比一个等价的命令行工具多花三倍 token、延迟翻一倍以上。

于是他自己定了一套标准叫 AXI，核心思想是把 agent 当"一等用户"来设计工具接口，专门优化给 agent 用的人机工程学。比如换一种省 token 的输出格式，比 JSON 能省大约 40%。

这件事给我的启发是：光换更强的模型没用，你得回头看看你塞给 agent 的那把"锤子"是不是趁手。

他还有个工具让我眼前一亮，叫 Lavish。规划复杂功能时，大多数 agent 给你吐一大段 markdown 文字墙，难读，也没法精确指着某一句说"这里不对"。Lavish 让 agent 直接生成一个可视化 HTML 原型，用的就是你这个项目本身的设计风格，你能在上面圈点、批注、直接反馈。规划阶段把需求聊透了，实现阶段他基本不用插手。

## 循环、并行与那个"大副"

质量闸交给流水线之后，中间那一大段全是 agent 在跑。Kun 接着问：怎么让 agent 在中间忙得更久？

他的答案有点极端：睡觉的 8 小时，怎么让 agent 一直跑？为此他写了个工具叫 Goodnight Have Fun——给它一个目标和一组停止条件，它就一直循环跑，直到撞上你设的边界。他真干过这么一件事："假装你是个 7 岁小孩，从头到尾用这个 App，找出第一个让你困惑、不知道怎么继续的可用性问题，找到就停下来修，然后重复。"他去睡觉，醒来看一晚上攒下的提交记录，挑想要的合入。

这就是我之前写过的"循环工程"——最顶尖的工程师已经不亲自写提示词了，他们在写循环。而且你留意一下：这个"8 小时"的数字，待会儿你会在 AgentCore 那边一字不差地再看到一次。

跑得久之后是跑得多。多个 agent 在同一个目录里会互相踩，标准解法是 git worktree（给仓库开独立副本）。但 worktree 多了之后，哪个在跑、哪个空着、哪个卡住了，全得记在脑子里，脑力负担很大。于是他又写了个工具 Treehouse，专门替他管这些 worktree 的生命周期。

到最后同时开七八条线，光是在会话之间切换、提醒自己"这条在干嘛"，就累得像打地鼠。Kun 说，这时候你需要一个大副。

大副是又一个开源项目：一个你能像跟下属汇报一样对话的调度层。你跟它说"这三个项目都加个更新命令"，它自己判断出这是三个并行任务，自动用 Treehouse 开工作树、各派一个 agent 去干、各自跑 No Mistakes 验证、把 PR 备好等你审。你不再跟一堆 agent 打地鼠，你只跟大副一个人说话。

整条路到这里闭环了。Kun 的原话我特别认同：这需要一次思维转变——把精力从"亲手划桨"挪到"搞清楚什么才是重要的"：跟用户聊、看竞争格局、画一张好的路线图，带着你的舰队驶向对的方向。一旦你开始这么做，你就从水手变成了船长。

## 镜头拉到企业：AWS 的七个零件

现在把视角切到另一头。一家公司要让一支 agent 队伍安全地、规模化地服务真实用户，它面对的仍然是那五个子问题，只是多了多租户、安全合规、还要让普通工程师（没有 Kun 这种水平的个人）也能上手。

AWS 把这五件事打包成了 Amazon Bedrock AgentCore。2025 年 7 月预览，10 月正式可用，国内预计下个月开放。它拆成七个可以单独用、也可以拼起来用的组件：

- Runtime——agent 的 serverless 运行环境。每个会话待在独立隔离的容器里互不串扰，单个任务最长能跑 8 小时。对，就是 Kun 用 Goodnight Have Fun 想要的那个"跑通宵"，AWS 直接做进了底座。
- Memory——短期记忆管单次对话，长期记忆跨会话积累。对应 Kun 的记忆文件，只是从一个 markdown 文件变成了托管服务。
- Gateway——把你现成的 API、Lambda 函数一键包装成 agent 可调用的标准工具（走 MCP 协议），认证也替你处理。这就是 Kun 死磕的"工具人机工程学"，被做成了开箱即用的服务。
- Identity——agent 的身份凭证，让它能安全地以你的名义登录 GitHub、Slack、Salesforce，靠事先授权，密钥不用到处塞。
- Code Interpreter——一个沙箱，让 agent 跑自己生成的代码，跑错了也炸不到别处。
- Browser——云端浏览器，agent 自己开网页、点按钮、填表单，还能规模化地开很多个实例。
- Observability——agent 的"黑匣子"。每一步都记录：调了什么工具、走了哪条路径、在哪里走偏，全程可回放、可审计。这就是 AgentCore 版的质量闸，对应 Kun 那条 No Mistakes 流水线里"留证据、评风险、可追溯"的能力。

使用流程也很直接：照旧用你最顺手的框架写好 agent → 用它的 SDK 套一层壳、一句 agentcore launch 部署到 Runtime → 哪段缺哪段补地挂上 Memory、Gateway、Identity、Observability → 按用量付费。你的核心精力始终留在"这个 agent 到底解决什么业务问题"上，剩下的脏活它接走。

![demo 到生产，中间隔着一道鸿沟](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260623-demo-to-prod-gap.webp)

## 两张图，同一个形状

把 Kun 手搓的那一摞工具，和 AgentCore 的七个组件并排放，你会看到一种近乎诡异的对称：

<table> <thead> <tr> <th>一个人 · 手搓开源</th> <th>企业 · AgentCore 托管</th> </tr> </thead> <tbody> <tr> <td>让它跑通宵（Goodnight Have Fun）</td> <td>Runtime · 长时运行 8 小时</td> </tr> <tr> <td>工作树防互相踩脚（Treehouse）</td> <td>会话隔离 · 独立安全舱</td> </tr> <tr> <td>记忆文件 + 技能</td> <td>Memory · 短期 + 长期记忆</td> </tr> <tr> <td>工具人机工程学（AXI）</td> <td>Gateway · 把 API 变成 MCP 工具</td> </tr> <tr> <td>No Mistakes 质量闸</td> <td>Observability · 全程可回放可审计</td> </tr> <tr> <td>大副（调度多个 agent）</td> <td>编排调度层 · 企业 Agent 操作系统</td> </tr> </tbody> </table>

一个用免费开源工具在终端里搓，一个用托管服务在云上按量计费。解的是同一道题。这不是巧合。它说明"怎么运营一支 agent 舰队"这件事，已经从少数高手的私房手艺，沉淀成了一套有标准答案的工程。连云巨头都把它产品化了，意味着这道题的解空间已经被充分探索过。

![同一道题，两种答案](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260623-kun-vs-agentcore.webp)

## 工具会换，那道线不会

那你该学 Kun 那套终端工作流，还是直接上 AgentCore？

我的判断是：先别盯着工具，盯着那个思维切换。

你是个人开发者、想把自己的产能榨到极限，Kun 那套终端加开源工具几乎零成本，照着搭就能跑。你是企业、要让 agent 队伍安全服务真实用户、又不想每个团队各造一遍轮子，AgentCore 这种托管底座更省心。中间还有第三条路，也是我自己一个人在做的事：把这套能力包成普通人开箱即用的入口。你不用懂 Runtime、不用懂 MCP、更不用自己搭一条 No Mistakes 流水线，把要做的事说清楚，它帮你搞定图文创作和 PPT 生成。把这套能力做成企业能放心用的底座——Claude API 接入、综合服务、Token 用量管理、礼品方案——完整列表在这里，已经融进不少公司的真实流程，稳定、开箱即用。

Kun 在终端里手搓，AWS 在云上托管，我在给普通人做入口。三件事看着差着十万八千里，内核是同一句话：把那一整圈脏活咽下去，把最后那点轻松留给用它的人。

但工具终究会换。今天是 Claude Code 和 AgentCore，明天是别的名字；今天 Kun 手搓的那几个开源工具，下个月可能就被某个新产品覆盖。真正不会换的，是那条线：你愿不愿意从"亲手划桨、亲自审每一行"的水手，升级成"定标准、把质量闸、只在关键处做判断"的船长。

会写 agent 的人，AI 已经管够了。会带一支 agent 舰队、并且守得住那道不许糊弄的闸的人，永远不够。这是这个时代里，我看到的唯一确定不贬值的本事。

我是一个人做 AI 产品的创业者。如果你正打算从"用 AI 帮我写点东西"升级到"指挥一支 AI 舰队替我干活"，希望这篇能帮你看清前面这条路长什么样、坑在哪儿。