我们自己这几个月往 .claude/skills/ 里塞的东西越来越多，写博客、发飞书消息、查日志，大多是一个文件夹加几份 Markdown，很少再专门写一段 Python 脚本去处理某个特殊情况。AI Engineer World’s Fair 2026 第四天（官方叫 Day 4，我们内部按顺序称 Day 3）收官的这场分享，Google DeepMind 的 Philipp Schmid 把这个转变现场演示了一遍：同一个 GitHub PR review agent，他写了三个版本，一版比一版代码少。
原视频：https://www.youtube.com/watch?v=I2cbIws9j10（约 06:55:03 开始）
一个定义，和一个赌注
Schmid 开场先引用了 Simon Willison 对 agent 的定义：LLM agent 就是在循环里不停调用工具，直到达成目标。定义完，他把赌注摆上桌：接下来会用三种写法实现同一个 agent，一次比一次代码少、文件越用越多。按官方日程给出的时间线，三个版本分别对应 2025 年 1 月（硬写）、2025 年 10 月（简化）、和 2026 年现在（零代码）。
在动手之前，他先带出了 Gemini 新发布的 interactions API：一个统一接口，既能直接调用 Gemini 模型，也能调用 Google 自家的 agent，工具调用、多模态理解、多模态生成走同一套调用方式。过去的对话式 API 只认”用户说一句、模型答一句”这种轮次结构，聊天场景够用，但 agent 要处理的东西更杂：推理过程、工具调用、工具返回的结果，都得想办法塞进对话历史里，工程上只能硬用”用户”这个身份去搬运环境返回的数据。interactions API 把轮次换成了”steps”，用户输入、模型推理、函数调用、函数结果各自是独立类型。这更像是把一份闲聊记录换成一份带时间戳的工作日志，谁在什么时候做了什么一目了然，不用再假装是用户说的话。
版本一：一段 Python 循环要管的事
大约一年半前，写 agent 基本等于写一个 Python 循环：定义 JSON schema，写 Python 函数，拿到模型输出后判断这是一次函数调用还是一段文本，匹配对应类型再去调用工具，出错了还要写重试逻辑。Schmid 现场展示了这一版：一个类、一个调用 interactions API 的 run 函数，里面塞满了函数调用、函数结果、错误处理的分支判断。系统提示单独放一个文件，工具的 JSON schema 单独定义，GitHub API 的调用逻辑再单独实现。
demo 没出岔子：打个招呼，它回一句自我介绍；丢给它一个真实 PR 去审，函数调用和返回结果一步步走完，能用。但只要问一句”旧金山今天天气怎么样”，它就只会说”我做不到这件事”，因为没人给它定义查天气的工具。这一版能跑，代价是一大堆文件、一大堆容易出错的地方、以及需要持续维护的代码量。
版本二：框架接管了循环，但 Python 还得自己写
再往后，agent 框架出现了，Schmid 举了 Google 自家的 ADK 框架做例子：一个 Agent 类接管了工具调用循环、重试、错误处理，把之前手写的样板代码全部吸收掉。回到 demo，第二版里那个专门的 agent 文件消失了，提示词和工具还在，但工具的 JSON schema 不用再手写。框架直接从 Python 函数签名反推出 schema。运行效果和第一版接近，审 PR 能走通，问天气依然被拒绝，因为没有定义对应工具这件事本身没变。
框架解决了轮次调度、工具路由、schema 生成这些管道工作，但工具本身的 Python 实现、运行环境、部署方式，仍然要自己动手。少了循环控制的代码，Python 插件式的工具函数还在。
版本三：把工具变成文件
真正的转折发生在 Google I/O 发布的 Antigravity 远程 agent 上。它和 Antigravity IDE 用的是同一套 agent harness，但不是同一个 agent——IDE 里那个是专门写代码的，Gemini API 里这个是通用型的，工具集也不完全一样（比如 API 版自带 Google 搜索）。关键新增是一个 environment 参数：agent 可以拿到一个隔离的云端沙箱，能跑 bash 命令、能存文件，环境里放的资源可以是一个 GitHub 仓库、一个 GCS bucket，也可以是直接内联的文件。
安全上的做法是在沙箱外面套一层网络代理：只有当 agent 从沙箱内部往外发请求时，代理才把对应凭证注入进去，agent 本身从没见过任何密钥，它只知道”我可以调 GitHub API”。域名访问也能限制，默认是不设限。Schmid 的解释很直接：如果每次都得先声明能访问哪些网站，用起来就是个麻烦，索性先保持简单。
到这一版，demo 里的”source”目录彻底消失了，取而代之的是一个 agents 文件夹，里面一份 agents.md 写系统提示：内容和之前几乎一样，唯一区别是告诉 agent”你有 GitHub CLI 可以用，有 bash 工具，有文件系统，你觉得该用就用”。因为沙箱里没预装 GitHub CLI，配了一段基础的 bash 脚本，第一次运行时检测到没装就自动装上。
现场运行这一版时，agent 先探索沙箱确认有没有装 GitHub CLI，发现没有就自己装上，然后用 GitHub CLI 加上自己已有的知识去完成 PR 审查，不再依赖预先定义好的函数调用。再问一次旧金山天气，这次 agent 直接用上了 Gemini API 自带的 Google 搜索工具，查到当天大约 20 摄氏度，答上来了。同一个问题，版本一二答不出来是因为没人预先声明这个能力，版本三答得出来，是因为不再需要逐个声明工具，模型被信任去自己判断该用什么、怎么用。
这一版的代码接口也简单到只剩：一个装 CLI 的 bash 脚本、一份 agents.md、外加告诉 agent 可以用哪些带凭证的 API（GitHub 的 API 域名和 github.com 域名各建一个 token，一个给 git 命令用，一个给 http 请求用），域名策略写”all”就是可以访问全网但没有凭证。剩下的就是一次 API 调用：传用户输入、传 environment、传上一次的 interaction ID 保持多轮对话连续。后端接到这一次调用，启动云沙箱，加载 agents.md 和 environment 里的 skill 文件，模型在 API 和沙箱之间自己完成调用、返回、再调用的整个循环。
这一版之后，团队不再需要自己写循环、不用自己做工具路由，会话状态在服务端维护，只管往里喂新的输入；上下文窗口的压缩也是自动的。剩下还要做的事，是写清楚 agents.md 里的规则和行为、把能力和上下文写进 skill 文件、以及把评估体系做扎实——这部分工作量并没有消失，只是从写循环控制代码变成了写清楚的说明文档。以前想给这个 PR review agent 加一个安全扫描能力，得写新的 Python 函数、定义新的 schema、加进工具列表、再跑通；现在只需要多加一份 skill 文件说明用什么命令行工具，或者把工具本身放进 environment 里，不用碰代码，agent 自己会判断什么时候该用。
Cursor 的 12000 行，和三个团队的返工账
Schmid 举了几个真实的产业案例给这条论证托底。Cursor 团队在 AI Engineer 欧洲站的分享里提到，他们原来给 git worktree 编排写了大约 12000 行 TypeScript，硬编码怎么开分支、怎么合并、怎么清理；后来换成大约 200 行的 agent files 就做到了同样的效果。这不只是代码量少了六十倍这么简单——那 12000 行里的大部分逻辑，其实是分支管理的常识判断，本该由模型自己拿主意，团队之前一直在替模型做这些决定。
另外三个数字更值得留意：Manus 去年半年里把自己的 agent harness 重写了 5 次，Langchain 一年里把 open deep research 的架构改了 3 次，Vercel 直接砍掉了 80% 的工具定义换来更少步骤、更快响应、更高准确率。有点讽刺的是，这几个团队都是最早一批把 agent harness 做厚的人，现在反过来不断拆自己搭的脚手架。Schmid 给的结论很干脆：如果模型能力在变强，你的 harness 却越改越复杂，大概率是你在过度工程，而不是模型没跟上。
这是下午 harness engineering track 收官的最后一场
按官方日程，这场 3:45pm-4:05pm 排在 Main Stage 的 Harness Engineering 分轨最后一格，前面接连是”Agent Frameworks Considered Harmful”、”No Memory, No Harness: Why the Database Is the Last Line of Defense”这类同一主线的分享，之后主舞台就切回全场 keynote。一整个下午都在绕同一件事打转：怎么用结构化的配置去管住 agent，而不是靠手写代码堆控制流。Schmid 这场把这条线推到了目前能推的最远处——从”写循环”到”配框架”再到”扔文件”，代码这条轴几乎归零，剩下的全是给模型看的说明书。
延伸：我们自己也在这么干
这条判断我们自己的知识库其实已经追了小半年。Kangwook Lee 提出的 Three Regimes 框架说过一句更狠的话：过去造 harness 的人是人类自己（h_good = h_human），现在造 harness 更好的反而是 AI 自己（h_good = h_ai）——继续手搓 harness，等于把中段模型摁在能力线以下。Garry Tan 说的”Thin Harness, Fat Skills”也是同一个方向：代码那层越写越薄，skill 文件那层越用越厚。Anthropic 内部流出的配置里，Skills 被明确定义为”一个文件夹，不是一个文件”：SKILL.md 加 references 加 assets，跟 Schmid demo 里 agents.md 加 skill.md 加 bash 脚本的结构几乎是一回事，只是换了个厂牌的命名。
这场分享补上的，是一份可以现场重现的对照实验：同一个任务，三种写法，谁多谁少一目了然。它还带来一个我们之前没记录过的产品细节：Google 用 Antigravity agent、environment 沙箱、interactions API 这一整套去回应 Anthropic 用 Claude Code 和 Skills 体系解决的同一个问题，两家的路数越来越像。
落到我们自己头上更直接：.claude/skills/ 底下那几十个技能包，就是这条判断的实操版本，真正花心思写的不是控制流代码，是把规则、边界、评估标准讲清楚的说明文档。如果哪天发现自己的 harness 随着模型升级反而越改越臃肿，该做的事是定期做减法，看看哪些判断已经能还给模型了。
Codex CLI 深度
AI 模型横评
AI Agent 框架
Claude Code 订阅生存指南