首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >AGENTS.md、Skills 和 Sandbox 为什么一起火了

AGENTS.md、Skills 和 Sandbox 为什么一起火了

作者头像
随机比特
发布2026-03-30 16:36:34
发布2026-03-30 16:36:34
2260
举报

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

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

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

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

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

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

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

  • AGENTS.md:告诉 agent 这地方怎么干活,边界在哪,先读什么,别碰什么
  • Skills:把重复动作沉淀成能力,不要每次现编现试
  • Sandbox:把风险关起来,让 agent 能跑,但别一路跑进线上事故

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

···

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

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

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

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

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

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

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

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

  • 你是谁
  • 你该优先读什么
  • 你在哪个目录工作
  • 哪些动作要先确认
  • 出错了该停在哪
  • 这套系统的共享状态放哪

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

01-stack
01-stack

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

···

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

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

其实不是。

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

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

比如:

  • 哪些文件是共享状态,不能乱写
  • 哪些操作属于对外动作,必须先停下来
  • 遇到登录态失效、端口异常、人机验证时,是重试、降级还是直接停止
  • 写完以后该更新哪份状态文件,不能乐观标记成“已完成”

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

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

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

这是两件完全不同的事。

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

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

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

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

···

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

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

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

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

这其实很浪费。

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

Skills 的价值就在这。

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

  • 什么时候必须先读 persona
  • 什么时候要检查 trending 质量等级
  • 什么时候能自动继续,什么时候必须停在人工闸门前
  • 公众号草稿、封面、小红书文案、X dry-run 分别走哪条路径

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

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

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

所以我现在越来越相信:

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

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

···

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

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

这就是 Sandbox 的位置。

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

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

一旦它要:

  • 跑命令
  • 改文件
  • 接浏览器
  • 调外部服务
  • 触达线上状态

你就会开始犹豫。

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

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

比如:

  • 限定工作目录
  • 限制可调用命令
  • 把上传路径收口到固定临时目录
  • 对高风险动作单独审批
  • 失败时停止,不继续连锁执行
02-shift
02-shift

这也是为什么我觉得,最近大家同时在谈 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。

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

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

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

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

随时接管。

也就是:

  • AI 能先跑一段
  • 关键节点停住
  • 失败时留下清晰现场
  • 人能低成本接上去

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

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

你更该先得到一个:

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

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

···

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

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

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

别急着堆长提示词。

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

2. 把重复动作收敛成 Skills

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

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

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

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

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

4. 为失败设计出口

不要只设计 happy path。

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

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

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

03-checklist
03-checklist

···

最后一句

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

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

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

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

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

AGENTS.md 是边界。

Skills 是复用。

Sandbox 是胆量。

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

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

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-03-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 随机比特 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 以前我们卷 prompt,现在开始卷工作说明书
  • AGENTS.md 管的不是语气,是边界
  • Skills 真正解决的,是“别每次都重新教”
  • 但只有 AGENTS.md 和 Skills 还不够,Sandbox 才决定你敢不敢放手
  • 多 agent 真正放大的,不只是效率,还有混乱
  • 对普通团队来说,最值钱的不是“全自动”,而是“可接管”
  • 我觉得接下来一年,真正值得卷的是这 5 件事
    • 1. 先写入口规则,再写 prompt
    • 2. 把重复动作收敛成 Skills
    • 3. 高风险动作一定要有闸门
    • 4. 为失败设计出口
    • 5. 多 agent 之前先管好共享状态
  • 最后一句
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档