最近我连着看了两样东西，看完脑子里「咔哒」一声，有些东西对上了。
第一样，是一个叫 Kun 的工程师录的 45 分钟工作流演练。这人来头不小：前 Meta、微软、Atlassian 的 L8 首席工程师，干过 Bing 搜索、Windows、Facebook 游戏这种大系统。他说自己现在一个人，每天提交 40 到 50 个 PR，而且不是社交媒体上那种随手糊一个 Minecraft demo，是经过完整测试、已经上了生产的代码。
第二样，是 AWS 刚正式发布的一个产品——Amazon Bedrock AgentCore。
一个是个人在终端里手搓的开源工具集，一个是云巨头的企业级托管产品，八竿子打不着。可我把这两样东西摆在一起看，越看越觉得：它俩在解同一道题。
而这道题，恰恰是我这阵子一直在唠叨的那句话——做 Agent，最难的从来不是那个 Agent 本身。
先说清楚这道题：会写 ≠ 会运营
现在做一个会自己规划、自己调工具的 Agent demo，是个人都能办到。拉一支 AI 大军、一个周末出一个惊艳的东西，门槛低到尘埃里。
但我之前讲过一个「POC 幻觉」：Demo 成功 ≠ 产品成功。 demo 跑得通，和能真上生产、能持续干活，中间隔着一整段路。
Kun 这套工作流和 AWS 这个产品，干的都是这一段。他们要解决的，不是「怎么让 agent 更聪明」——那是模型公司的事；而是「怎么让一群 agent 替你持续、稳定、有质量地干活」。
我把这道题拆成五个小问题，你会发现 Kun 和 AWS 是从两端，给出了几乎一模一样的答案：
- 怎么让 agent 跑得久，而不是一跑就崩、一关机就没；
- 怎么让多个 agent 同时干活又不互相踩脚；
- 怎么让 agent 记得住之前的事，越用越聪明；
- 怎么让 agent 高效、安全地调用工具；
- 怎么在 agent 干完活之后，守住质量、又不被它的速度拖垮。
先看一个人能把这五件事做到什么程度。
第一条路：一个人，怎么指挥一支舰队
Kun 把整套工作流包装成一个航海的比喻：你是船长，agent 是船员，你要做的是开船，不是自己划桨。 我觉得这个比喻特别准，顺着它往下讲。
先把驾驶舱收拾利索
很难不注意到的一点：他几乎所有操作都在终端里完成。终端模拟器、Tmux 分屏、Neovim 编辑器，一套下来花里胡哨。
但他选终端的理由特别朴素，就两条：一是手不用离开键盘——每次手从键盘挪到鼠标，都是一次注意力的打断、一次大脑的上下文切换，听着小，累积起来惊人；二是到哪儿都是同一套环境，Tmux 会话是持久的，他从电脑上分离，回头用手机连上同一个会话，接着干。
这背后是一个很容易被忽略的道理：当你要同时盯很多个 agent，你自己「切换的成本」会变成最大的瓶颈。 他先把驾驶舱收拾到切换成本几乎为零，后面才谈得上同时开很多条线。
船员是可替换的，别跟某一个绑死
他常用的 agent 工具有四个：Claude Code、Codex CLI、还有一个极简的 Python agent、以及 OpenCode。但他反复强调一件事：他刻意让整套工作流「与 agent 无关」。
为什么？因为「下个月哪个模型、哪个工具最强」根本说不准。这话我太有共鸣了——这正是我说的「起跑线天天被重置」。所以聪明的做法不是押注某一个船员，而是把你的流程、你的标准沉淀下来，让任何一个船员上船都能照着干。 船员可以换，船长的章法不能换。
怎么「培训」船员：记忆 + 技能
新船员上船，不懂你的规矩，得有个「入职培训」。Kun 用两样东西做这件事。
一是记忆文件。 全局的那份他写得极克制，只有 27 行。因为这个文件每次会话都会被塞进系统提示，写多了就是在悄悄烧 token。里面主要是他的个人偏好，比如「别用那种 AI 味的长破折号」。
这里有个特别值钱的洞察，我得单独拎出来说。他在记忆里专门写了一条规矩：做技术决策时，不要高估开发成本。 为什么？因为模型是拿人类数据训练的，你问它「做个 3D 射击游戏要多久」，它会像个普通程序员一样答「几天到几周」——可你真让它现在就动手，几分钟就能给你一个能玩的版本。AI 还没意识到自己写代码比人快得多。 这个认知错位会让它在做选择时，偏向那些「省开发量」但其实低质、难维护、不可扩展的廉价方案。所以他写一条规矩，专门去掰正这个偏见。
这种东西，才是真正的经验。它不在任何模型的参数里，是一个人趴在一线，被坑过无数次之后，一条条喂给机器的。
二是技能（skill）。 记忆文件会越来越臃肿，他的办法是把那些「不是每次都用」的知识，挪进技能里。技能的妙处在于渐进式披露：平时只把一行简介加载进系统提示，只有 agent 真觉得需要时，才去读技能的完整内容。这样你能存海量的「怎么做某件事」的知识，却不会每个请求都为它烧 token。
他还泼了盆冷水，我特别想转给所有人：别从网上随便装技能，哪怕它 GitHub 星标爆表。 一是安全——一个技能可以指示你的 agent 在你机器上干任何事，泄露 API 密钥甚至银行凭据；二是性能——他拿一个挂着 Karpathy 名号、17.7 万星的技能仓库做实测，结果用了它之后，agent 多烧 5% 的 token，效果反而更差，而且那东西压根不是 Karpathy 本人写的。一句话：受欢迎，不等于真的好。 大量被疯转的技能，从没经过任何严肃评测，只是某个人偶然觉得「对我管用」，然后莫名其妙就火了。
会判断「哪个有用、哪个是噪音」，本身就是船长的核心能力。
怎么跟船员说话：语音 + 给它一副好工具
跟 agent 沟通，他基本不打字了，改用语音。斯坦福有篇正经论文做过对比，说话比打字快三倍。有意思的是，那篇论文的参考文献里还挂着 Anthropic CEO Dario 的名字——他 2016 年搞过语音识别，现在我们用语音跟 Claude 说话，Claude 又是他公司做的。世界真小。
比语音更值得说的，是他对工具效率的较真。agent 干活要靠外部工具，而工具怎么设计，会极大影响 agent 的表现。他举了个例子：很多人用 GitHub 的 MCP 服务器去访问 GitHub，但他实测发现，干同样的活，用 MCP 比用一个命令行工具多花三倍 token、延迟翻一倍还多。
于是他自己定了一套标准，叫 AXI——核心思想是把 agent 当成「一等用户」来设计工具，专门优化「给 agent 用」的人机工程学。比如换一种省 token 的输出格式，比 JSON 能省大约 40% 的 token。
这件事的启发是：agent 的产出质量，被它手里工具的质量死死卡住。 你光换更强的模型没用，得回头看看，你给它的那把「锤子」是不是趁手。
他还有个让我眼前一亮的工具叫 Lavish。规划一个复杂功能时，大多数 agent 给你吐一大段 markdown「文字墙」，又难读、又没法精确指着某一句说「这里不对」。Lavish 让 agent 直接生成一个可视化的 HTML 原型，而且用的就是你这个项目本身的设计风格，你能在上面圈圈点点、直接批注反馈。规划阶段把需求聊清楚了，实现阶段他基本不用插手。
真正的分水岭：那道「质量闸」
前面都是铺垫，这一段才是整套工作流的命门，也是我看完最激动的地方。
当 agent 说「我干完了」，才是最危险的时刻。
大多数人这时会打开编辑器，开始一行行审 diff。Kun 说这是个陷阱：AI 写代码太快了，如果每一段都要你审，你自己就成了那个最大的瓶颈。 你一天能审的 diff 是有限的，你的产能就被死死焊在这个上限上。更何况，审 diff 一点都不好玩，没人当工程师是为了整天看 diff。
他的解法，是一次彻底的身份转变：别再把自己当水手，把自己当工程总监。 总监不审每一个 PR，他靠的是建立一套好的流程和文化，然后信任团队去执行。
于是他搭了一条开源流水线，名字起得很狠，叫 No Mistakes（不许出错）。agent 说干完了，他不看 diff、不手动测，直接把改动丢进这条流水线，它会自动走完一串步骤：
- 先拉一个隔离的工作树，整个验证过程不污染你当前的仓库；
- 分析 agent 这次会话，搞清楚你这次改动「真正的意图」是什么；
- 把代码 rebase 到最新主干，提前把合并冲突解掉；
- 然后在一个全新的上下文窗口里，发起一轮「对抗式审查」——他说，大多数问题就是在这一步被揪出来的。明显的问题它自己改掉，那种「有产品影响、说不清对错」的模糊问题，才升级给人来拍板；
- 接着端到端测试，并且录下证据——截图、录屏、日志，证明这玩意儿真的在工作；
- 最后更新文档、过一遍 lint，推分支、提 PR，还一路盯着这个 PR 直到它合并，中间再遇到冲突或 CI 失败它也帮你扛。
流水线还会给一份风险评估。Kun 就靠这个决定自己要花多少精力去看：低风险的改动，他根本不看 diff——因为他反复验证过，他能挑出的毛病，流水线大概率已经抓到了；只有高风险的，才值得他亲自出手。
看到这儿你大概明白我为什么激动了。这不就是我念叨过无数次的「质量闸」吗？ 我在写「300 个 AI 筛电动车公司」那篇时说过：机器负责快，人负责判断对错真假好坏；那个人了不起的地方，不是敢用 300 个 AI，是他敢逼着这些 AI 互相核对、反复打回，宁可慢三轮，也不放过一条假数据。Kun 的 No Mistakes，是同一个东西的工程化版本——有了这道闸，你才敢真的放手让 agent 替你干活。
让船开得更久、更多，最后请一个大副
把质量闸交给流水线之后，Kun 发现自己花时间的地方，只剩任务的头和尾：开头在 Lavish 里把需求规划清楚，结尾把控质量。中间那一大段，全是 agent 在干。
中间腾出的时间越多，他能并行跑的活就越多。于是问题变成：怎么让 agent 在中间忙得更久？
他的答案有点极端：他睡觉的时候，怎么让 agent 忙 8 个小时？ 为此他做了个工具叫 Goodnight Have Fun——给它一个目标，它就一直循环跑，直到撞上你设定的停止条件。比如他真干过：「假装你是个 7 岁小孩，从头到尾用这个 App，找出第一个让你困惑、不知道怎么继续的可用性问题，找到就停下来修，然后重复。」他去睡觉，醒来看一晚上攒下的提交，挑想要的。
这不就是我写过的「循环工程」吗——最顶尖的工程师，已经不亲自写提示词了，他们在写「循环」。而且你注意到没有：他想让 agent 跑通宵的那个「8 小时」，待会儿你会在 AgentCore 那边，一字不差地再见到一次。
跑得久之后是跑得多。多个 agent 在同一个目录里会互相踩脚，标准解法是 git worktree（给仓库开一个独立副本），但 worktree 多了又变成脑力负担——哪个在跑、哪个空着，全得记在脑子里。于是他又做了个工具 Treehouse，专门替他管这些 worktree。
到最后，同时开七八条线，光是在这些会话之间切换、提醒自己「这条在干嘛」，就累得像打地鼠。Kun 说，这时候他需要一个大副。
大副是又一个开源项目：一个你能像对船长汇报一样对话的调度者。你跟它说「这三个项目都加个更新命令」，它自己判断出这是三个并行任务，自动用 Treehouse 开工作树、各派一个 agent 去干、再各自跑 No Mistakes 验证、把 PR 备好等你审。你不再跟一堆船员打地鼠，你只跟大副一个人说话。
讲到这儿，整条路就闭环了。Kun 的原话我很喜欢：这需要一次思维的转变——把精力更多放到「搞清楚什么才是重要的」上：去跟用户聊、去看竞争格局、去画一张好的藏宝图，带着你的舰队驶向对的方向。一旦你开始这么做，恭喜，你就从一个水手，变成了一个真正的船长。
第二条路：把镜头拉到企业，AWS 的工业级答案
现在请你记住上面那五个小问题，和 Kun 为每一个手搓的那个工具。
然后我们换个视角：一家公司想干同样的事——让一支 agent 队伍安全地、规模化地服务真实用户。它面对的是完全一样的五个问题，只是规模更大、要多租户、要安全合规、还得让不是 Kun 这种高手的普通工程师也能用。
AWS 把这五件事打包成了一个产品，就是 Amazon Bedrock AgentCore。2025 年 7 月发的预览，10 月已经正式可用，国内预计下个月也能用上。它不是一个大黑盒，是七个能单独用、也能拼起来用的零件：
- Runtime——agent 的「服务器 + 保安」。serverless 运行环境，每个会话待在自己独立隔离的舱里互不串扰，单个任务最长能跑 8 小时。看到这个 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 流水线里「留证据、可审计、评风险」的能力。
它最聪明的设计和 Kun 的章法也是一致的：框架无关、模型无关。 你用 LangGraph、CrewAI、LlamaIndex、还是 AWS 自己的 Strands 写的都行，配什么大模型也随你。它不抢「写 agent」这件最有创造性的活，只接管你写完之后那一整圈脏活——官方那句话很到位：同一份在你笔记本上跑的代码，几乎能原样部署到生产。
怎么用？流程很简单：照旧用你最顺手的框架写好 agent → 用它的 SDK 套一层壳、一句 agentcore launch 部署到 Runtime → 哪段缺哪段补地挂上 Memory、Gateway、Identity、Observability → 按用量付费，用多少算多少。你的核心精力始终在第一步「这个 agent 到底解决什么业务问题」上，剩下的基础设施，它替你接走。
两条路，其实是同一张图
你把 Kun 手搓的那一摞工具，和 AgentCore 的七个零件并排放，会看到一种近乎诡异的对称：
| 一个人 · 手搓开源 | 企业 · AgentCore 托管 |
|---|---|
| 让它跑通宵（Goodnight Have Fun） | Runtime · 长时运行 8 小时 |
| 工作树防互相踩脚（Treehouse） | 会话隔离 · 独立安全舱 |
| 记忆文件 + 技能 | Memory · 短期 + 长期记忆 |
| 工具人机工程学（AXI） | Gateway · 把 API 变成 MCP 工具 |
| No Mistakes 质量闸 | Observability · 全程可回放可审计 |
| 大副（调度多个 agent） | 编排调度层 · 企业 Agent 操作系统 |
一个用免费开源工具在终端里手搓，一个用托管服务在云上卖钱，可它们解的是同一道题。 这不是巧合。这说明「怎么运营一支 agent 舰队」这件事，已经从少数高手的私房手艺，沉淀成了一套有标准答案的工程，连云巨头都来把它产品化了。
写在最后：工具会换，那道分水岭不会
那你该学 Kun 那套，还是上 AgentCore？
我的答案是：先别盯着工具，盯着那个思维转变。
你是个人开发者、想榨干自己的产能，那 Kun 那套终端加开源工具，几乎零成本，照着搭就能用。你是企业、要让一支 agent 队伍安全服务真实用户、又不想每个团队各造一遍轮子，那 AgentCore 这种托管底座更省心。中间还有像我这样的第三条路——把这套能力包成普通人开箱即用的入口。
这也正是我一个人做 Zaokit 在干的事：你不用懂 Runtime、不用懂 MCP、更不用自己搭一条 No Mistakes 流水线，把要做的事说清楚，它就帮你麻利地搞定图文创作和 PPT 生成。唯一网站：https://zaokit.app。把这套能力做成企业能放心用的全家桶，也是我一直在做的：cx.zaokit.com、cc.zaokit.com、tokenhub.zaokit.ai、gift.junxinzhang.com 以及更多项目，已经融进不少公司的真实流程，稳定靠谱、开箱即用。
Kun 在终端里手搓、AWS 在云上托管、我在给普通人做入口——三件事看着差着十万八千里，内核是同一句：把那一整圈脏活咽下去，把最后那点轻松，留给用它的人。
但工具终究会换。今天是 Claude Code 和 AgentCore，明天是别的；今天 Kun 手搓的几个开源工具，说不定下个月就被某个新产品取代。真正不会换的，是那道分水岭：你愿不愿意从一个「亲手划桨、亲自审每一行」的水手，升级成一个「定标准、把质量闸、只在关键处做判断」的船长。
会写 agent 的人，AI 已经管够了；会带一支 agent 舰队、并且守得住那道不许糊弄的闸的人，永远不够。 这才是这个时代，唯一确定不贬值的本事。
我是 Jason，一个自己一个人做 AI 产品的创业者。如果你正打算从「用 AI 帮我写点东西」升级到「指挥一支 AI 舰队替我干活」，希望这篇能帮你看清，前面这条路长什么样、坑在哪儿。
相关阅读：
过去三个月，刷屏的 AI 项目几乎全凉了——拼执行速度的时代过去了，现在拼的是判断速度