← 随机比特 / 所有内容

agents md skills workflow

2026-03-19 · 随机比特

AI 不缺答案,缺的是工作方式:AGENTS.md、Skills 和 Sandbox 为什么一起火了

这两天我越来越强烈地觉得,AI 圈真正重要的变化,不是又来了一个更强模型。

而是大家终于开始认真处理一件更朴素、也更难的事:怎么让 AI 稳定地干活。

以前我们讨论 AI,重点几乎都在“会不会答”“答得像不像人”“代码写得快不快”。现在风向明显变了。越来越多团队开始谈 AGENTS.md、Skills、Sandbox、多 agent workflow,甚至把“测试、回放、接管点、失败出口”放到模型能力前面。

说人话就是:大家开始发现,AI 最大的问题不是不聪明,而是没有工作方式

你给它一条 prompt,它可能能完成一次任务。

但你要它明天继续做、换个场景还会做、失败后别把现场搞烂,还能被别人接手——这时候,光靠 prompt 就不够了。

这也是为什么我觉得,今天最值得写的,不是哪家又出了新模型,而是这套正在成型的底层抽象:

这三样放在一起,AI 才开始有点“可复用劳动力”的样子。


以前我们卷 prompt,现在开始卷工作说明书

前一阶段最流行的叙事,是提示词工程。

谁写的 prompt 更长、更细、更像咒语,谁就更像掌握了 AI 的用法。

这套东西不是没用,但问题也很明显:它太依赖单次对话了。

你今天调通了,明天换个任务可能又失效;你自己知道为什么这么写,换个人接手就要从头猜;一旦接浏览器、脚本、文件系统、消息渠道,问题更不是“这句话怎么说”能解决的。

所以现在很多 agent 系统都在往另一个方向走:把工作方式从 prompt 里拆出来,变成结构化约束。

这也是 AGENTS.md 这种东西突然变重要的原因。

它本质上不是“再来一份说明文档”,而是在告诉 agent:

这些规则一旦从脑内经验变成文件,工作流就开始从“靠人盯着”变成“别人也能接得住”。

<figure><img src=“images/01-stack.png” alt=“01-stack”></figure>

这一步看起来没那么酷,但它是 agent 从 demo 走向日常使用的分水岭。


AGENTS.md 管的不是语气,是边界

很多人第一次看到 AGENTS.md,会以为它只是“给 AI 的 README”。

其实不是。

我更愿意把它理解成一份工作现场说明书

它最重要的作用,不是让 AI 更会说话,而是让它少犯那种代价很高的错。

比如:

这些约束,如果只存在人的脑子里,agent 一旦换模型、换入口、换子任务,就很容易漂。

但如果它被写成固定文件,放在工作流入口,很多问题会立刻变得清楚:

不是“AI 又抽风了”,而是“它没有按现场规则做事”。

这是两件完全不同的事。

我自己的体感是,一旦开始认真写 AGENTS.md,你看 agent 的视角也会变。

你不再只是问“它聪不聪明”,而会开始问:

它知道自己该在哪停吗?它知道哪些状态不能碰吗?它失败后留给人的现场干净吗?

这才是工程问题真正开始的地方。


Skills 真正解决的,是“别每次都重新教”

如果说 AGENTS.md 负责边界,那 Skills 负责的就是复用。

我很不喜欢一种常见状态:每次让 AI 做同一类事,都像第一次上岗。

今天教它写公众号草稿,明天教它排版,后天再教它怎么去重、怎么做封面、怎么注入草稿箱。看起来都是同一个 agent,但每次都得重新交底。

这其实很浪费。

因为很多动作明明已经稳定了,应该被沉淀成能力,而不是继续藏在一大段 prompt 里。

Skills 的价值就在这。

它把“重复但需要判断”的动作,收敛成可调用模块。比如:

这种抽象的好处,是让 agent 的能力不再只是一坨“会聊天的上下文”,而开始像一套可维护的操作系统扩展

而且它还有一个很现实的好处:降低重试成本。

一旦某步出错,你修的是技能或者流程,不是再从头跟模型吵一遍。

所以我现在越来越相信:

真正高频的 AI 使用,最后都会从 prompt collection 变成 skill library。

你收集的不是“神奇咒语”,而是“哪些动作值得被固化”。


但只有 AGENTS.md 和 Skills 还不够,Sandbox 才决定你敢不敢放手

很多人对 agent 最大的不安,不是它不会干活,而是它会不会乱干活

这就是 Sandbox 的位置。

我觉得 Sandbox 不是一个安全装饰件,而是 agent workflow 的心理阈值。

没有它,你就会本能地把 AI 限制在“回答问题”“写点草稿”“给点建议”这种低风险场景。

一旦它要:

你就会开始犹豫。

这种犹豫很正常。因为 agent 真正的价值,恰恰都在这些“能动手”的环节里。

所以 Sandbox 的意义,不是让风险消失,而是把风险变成可控范围内的风险

比如:

<figure><img src=“images/02-shift.png” alt=“02-shift”></figure>

这也是为什么我觉得,最近大家同时在谈 Skills 和 Sandbox,不是巧合。

前者解决“怎么更会做”,后者解决“为什么我敢让它做”。

没有后者,前者越强,很多人反而越不敢放出去跑。


多 agent 真正放大的,不只是效率,还有混乱

Cloud Agents、多 agent、subagents 这波热度很高。

这件事当然值得关注。因为一旦任务可以并行,吞吐真的会变化很大。

Cursor 现在讲的一个核心方向,就是把单人 IDE 使用习惯,推向 team workflow、并行 agent、自动测试、视频回放这些更完整的链路。这个方向本身没问题,而且很可能就是接下来一年的主旋律之一。

但我的看法是:

多 agent 最大的风险,不是模型不够强,而是你把混乱并行化了。

如果没有清楚的边界、技能分层、共享状态和失败出口,多开几个 agent 并不会自动更强,只会让错误更快扩散。

一个 agent 误写状态文件,是一次事故。

三个 agent 同时在脏状态上工作,就是一场排查灾难。

所以真正能撑起多 agent 的,从来不是“能开多少个窗口”,而是:

这也是为什么我会把 AGENTS.md、Skills、Sandbox 看成多 agent 之前的前置工程,而不是附属品。

你先把这些写清楚,多 agent 才是增益。

不然它只是在放大系统噪音。


对普通团队来说,最值钱的不是“全自动”,而是“可接管”

很多 agent 产品喜欢讲一个大愿景:

你只要说一句话,剩下都交给 AI。

这个画面很诱人,但真落到日常工作里,我反而越来越保守。

因为大多数真实流程都不是“一次性交付”这么简单。

它中间会有登录态、权限、外部页面、草稿、人审、品牌口径、风险边界。你想把这些都抹平,最后通常不是更顺,而是更脆。

所以对普通团队最值钱的,其实不是全自动,而是下面这四个字:

随时接管。

也就是:

这套思路听起来没那么激进,但它真的更适合大多数内容、运营、研发和自动化流程。

你不需要先追求一个“完全自治员工”。

你更该先得到一个:

会做事、能暂停、可复用、出错不失控的半自动搭子。

这个东西,价值反而更稳定。


我觉得接下来一年,真正值得卷的是这 5 件事

如果你也在搭自己的 AI 工作流,我会更建议你先卷下面这 5 件事,而不是先去追最新模型榜单。

1. 先写入口规则,再写 prompt

别急着堆长提示词。

先把目录边界、状态文件、外部动作、失败处理写清楚。很多混乱,根本不是模型太笨,而是入口信息太散。

2. 把重复动作收敛成 Skills

凡是你两次以上都在重复交代的动作,就值得抽出来。

“如何做一次”不重要,“下次还按同样方式做”才重要。

3. 高风险动作一定要有闸门

发消息、花钱、改线上状态、公开发布,这些动作别让 agent 默认直接穿透。

保留审批点,不是保守,是成熟。

4. 为失败设计出口

不要只设计 happy path。

真正决定体验的,往往是失败后有没有 clean stop、有没有中间产物、有没有可接管点。

5. 多 agent 之前先管好共享状态

一个状态文件谁能写,一个目录谁能改,一条链路谁是最终责任人,这些不先定,多 agent 大概率会先把你搞乱。

<figure><img src=“images/03-checklist.png” alt=“03-checklist”></figure>


最后一句

我现在越来越不把 AI 看成“会回答问题的超级搜索框”。

我更愿意把它看成一种正在形成中的新型工作接口。

它的上限当然还和模型有关。

但它能不能真正进入你的日常,越来越取决于另一件事:

你有没有把“怎么工作”这件事,写成 AI 真能执行的结构。

AGENTS.md 是边界。

Skills 是复用。

Sandbox 是胆量。

多 agent 只是把这套结构放大。

所以我的看法是,今天最值得关注的,不是“AI 又会了什么”,而是我们终于开始认真教它怎么在真实世界里干活。

你现在有给自己的 AI 写过“工作说明书”吗?

如果有,最有用的一条规则是什么?


参考来源

  1. Cursor’s Third Era: Cloud Agents
    https://www.latent.space/p/cursor-third-era
  2. 今日选题知识库与趋势汇总(内部整理)