
这两天我越来越强烈地觉得,AI 圈真正重要的变化,不是又来了一个更强模型。
而是大家终于开始认真处理一件更朴素、也更难的事:怎么让 AI 稳定地干活。
以前我们讨论 AI,重点几乎都在“会不会答”“答得像不像人”“代码写得快不快”。现在风向明显变了。越来越多团队开始谈 AGENTS.md、Skills、Sandbox、多 agent workflow,甚至把“测试、回放、接管点、失败出口”放到模型能力前面。
说人话就是:大家开始发现,AI 最大的问题不是不聪明,而是没有工作方式。
你给它一条 prompt,它可能能完成一次任务。
但你要它明天继续做、换个场景还会做、失败后别把现场搞烂,还能被别人接手——这时候,光靠 prompt 就不够了。
这也是为什么我觉得,今天最值得写的,不是哪家又出了新模型,而是这套正在成型的底层抽象:
这三样放在一起,AI 才开始有点“可复用劳动力”的样子。
···
前一阶段最流行的叙事,是提示词工程。
谁写的 prompt 更长、更细、更像咒语,谁就更像掌握了 AI 的用法。
这套东西不是没用,但问题也很明显:它太依赖单次对话了。
你今天调通了,明天换个任务可能又失效;你自己知道为什么这么写,换个人接手就要从头猜;一旦接浏览器、脚本、文件系统、消息渠道,问题更不是“这句话怎么说”能解决的。
所以现在很多 agent 系统都在往另一个方向走:把工作方式从 prompt 里拆出来,变成结构化约束。
这也是 AGENTS.md 这种东西突然变重要的原因。
它本质上不是“再来一份说明文档”,而是在告诉 agent:
这些规则一旦从脑内经验变成文件,工作流就开始从“靠人盯着”变成“别人也能接得住”。

这一步看起来没那么酷,但它是 agent 从 demo 走向日常使用的分水岭。
···
很多人第一次看到 AGENTS.md,会以为它只是“给 AI 的 README”。
其实不是。
我更愿意把它理解成一份工作现场说明书。
它最重要的作用,不是让 AI 更会说话,而是让它少犯那种代价很高的错。
比如:
这些约束,如果只存在人的脑子里,agent 一旦换模型、换入口、换子任务,就很容易漂。
但如果它被写成固定文件,放在工作流入口,很多问题会立刻变得清楚:
不是“AI 又抽风了”,而是“它没有按现场规则做事”。
这是两件完全不同的事。
我自己的体感是,一旦开始认真写 AGENTS.md,你看 agent 的视角也会变。
你不再只是问“它聪不聪明”,而会开始问:
它知道自己该在哪停吗?它知道哪些状态不能碰吗?它失败后留给人的现场干净吗?
这才是工程问题真正开始的地方。
···
如果说 AGENTS.md 负责边界,那 Skills 负责的就是复用。
我很不喜欢一种常见状态:每次让 AI 做同一类事,都像第一次上岗。
今天教它写公众号草稿,明天教它排版,后天再教它怎么去重、怎么做封面、怎么注入草稿箱。看起来都是同一个 agent,但每次都得重新交底。
这其实很浪费。
因为很多动作明明已经稳定了,应该被沉淀成能力,而不是继续藏在一大段 prompt 里。
Skills 的价值就在这。
它把“重复但需要判断”的动作,收敛成可调用模块。比如:
这种抽象的好处,是让 agent 的能力不再只是一坨“会聊天的上下文”,而开始像一套可维护的操作系统扩展。
而且它还有一个很现实的好处:降低重试成本。
一旦某步出错,你修的是技能或者流程,不是再从头跟模型吵一遍。
所以我现在越来越相信:
真正高频的 AI 使用,最后都会从 prompt collection 变成 skill library。
你收集的不是“神奇咒语”,而是“哪些动作值得被固化”。
···
很多人对 agent 最大的不安,不是它不会干活,而是它会不会乱干活。
这就是 Sandbox 的位置。
我觉得 Sandbox 不是一个安全装饰件,而是 agent workflow 的心理阈值。
没有它,你就会本能地把 AI 限制在“回答问题”“写点草稿”“给点建议”这种低风险场景。
一旦它要:
你就会开始犹豫。
这种犹豫很正常。因为 agent 真正的价值,恰恰都在这些“能动手”的环节里。
所以 Sandbox 的意义,不是让风险消失,而是把风险变成可控范围内的风险。
比如:

这也是为什么我觉得,最近大家同时在谈 Skills 和 Sandbox,不是巧合。
前者解决“怎么更会做”,后者解决“为什么我敢让它做”。
没有后者,前者越强,很多人反而越不敢放出去跑。
···
Cloud Agents、多 agent、subagents 这波热度很高。
这件事当然值得关注。因为一旦任务可以并行,吞吐真的会变化很大。
Cursor 现在讲的一个核心方向,就是把单人 IDE 使用习惯,推向 team workflow、并行 agent、自动测试、视频回放这些更完整的链路。这个方向本身没问题,而且很可能就是接下来一年的主旋律之一。
但我的看法是:
多 agent 最大的风险,不是模型不够强,而是你把混乱并行化了。
如果没有清楚的边界、技能分层、共享状态和失败出口,多开几个 agent 并不会自动更强,只会让错误更快扩散。
一个 agent 误写状态文件,是一次事故。
三个 agent 同时在脏状态上工作,就是一场排查灾难。
所以真正能撑起多 agent 的,从来不是“能开多少个窗口”,而是:
这也是为什么我会把 AGENTS.md、Skills、Sandbox 看成多 agent 之前的前置工程,而不是附属品。
你先把这些写清楚,多 agent 才是增益。
不然它只是在放大系统噪音。
···
很多 agent 产品喜欢讲一个大愿景:
你只要说一句话,剩下都交给 AI。
这个画面很诱人,但真落到日常工作里,我反而越来越保守。
因为大多数真实流程都不是“一次性交付”这么简单。
它中间会有登录态、权限、外部页面、草稿、人审、品牌口径、风险边界。你想把这些都抹平,最后通常不是更顺,而是更脆。
所以对普通团队最值钱的,其实不是全自动,而是下面这四个字:
随时接管。
也就是:
这套思路听起来没那么激进,但它真的更适合大多数内容、运营、研发和自动化流程。
你不需要先追求一个“完全自治员工”。
你更该先得到一个:
会做事、能暂停、可复用、出错不失控的半自动搭子。
这个东西,价值反而更稳定。
···
如果你也在搭自己的 AI 工作流,我会更建议你先卷下面这 5 件事,而不是先去追最新模型榜单。
别急着堆长提示词。
先把目录边界、状态文件、外部动作、失败处理写清楚。很多混乱,根本不是模型太笨,而是入口信息太散。
凡是你两次以上都在重复交代的动作,就值得抽出来。
“如何做一次”不重要,“下次还按同样方式做”才重要。
发消息、花钱、改线上状态、公开发布,这些动作别让 agent 默认直接穿透。
保留审批点,不是保守,是成熟。
不要只设计 happy path。
真正决定体验的,往往是失败后有没有 clean stop、有没有中间产物、有没有可接管点。
一个状态文件谁能写,一个目录谁能改,一条链路谁是最终责任人,这些不先定,多 agent 大概率会先把你搞乱。

···
我现在越来越不把 AI 看成“会回答问题的超级搜索框”。
我更愿意把它看成一种正在形成中的新型工作接口。
它的上限当然还和模型有关。
但它能不能真正进入你的日常,越来越取决于另一件事:
你有没有把“怎么工作”这件事,写成 AI 真能执行的结构。
AGENTS.md 是边界。
Skills 是复用。
Sandbox 是胆量。
多 agent 只是把这套结构放大。
所以我的看法是,今天最值得关注的,不是“AI 又会了什么”,而是我们终于开始认真教它怎么在真实世界里干活。
你现在有给自己的 AI 写过“工作说明书”吗?
如果有,最有用的一条规则是什么?