4 月底，OpenAI 发布了 Codex CLI 0.128.0。更新日志里藏着一句话：「Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls.」几乎同一时间，Claude Code 也上线了 /goal 指令。Greg Brockman 在推特上写了一句：「codex now has a built-in Ralph loop++.」
大多数人把这条更新当作又一个 feature flag 滑过去了。但如果你仔细拆解 /goal 的设计，会发现它代表的不是「又一个功能」，而是 AI Agent 工程的一次范式跃迁。
6 月 9 日下午，我对 AI 说了一句「分析下本项目」。
4 秒后，它给了我一份完整的项目分析报告：13 个 JS 文件、6773 行代码、技术栈拆解、架构特点、功能清单。然后我说「在登录页面加个多语言切换」，它改了 3 个文件，跑了测试，commit，push，部署。全程我没打开过编辑器。
这不是一个 demo。这是一个跑在生产环境的全栈应用——带 CRDT 实时协同编辑、PWA 离线支持、三语国际化、OAuth 登录、AI 代理 Edge Function。35 次 commit，从 2 月到 6 月，每一行代码都是 AI 写的。
上个月有人问我一个问题：「我已经有 LLM-as-Judge 做 eval 了，能不能用它来自动优化 Agent 的执行路径？在不降质量的前提下，找到最省钱的轨迹，然后让 Agent 记住？」
这个问题的答案值得展开。答案是能，而且这可能是当前 Agent 优化里最值得投入的方向。但大多数团队理解错了「优化」的对象。
周一早上 9:30，一个 5 人 Scrum 团队的钉钉群里，AI 表格自动推送了一条晨会摘要：
📊 今日待办 7 项 （P0×2 / P1×3 / P2×2）
⚠️ 发现 3 个支付模块 bug 集中在支付网关，关联上周五 v2.3.1 发布。建议优先处理 #BUG-042，指派给 @张三（支付模块 owner）。
🔗 需求 #REQ-015 与 #BUG-039 存在依赖关系，建议先完成 bug 修复再启动需求开发。
工程师张三看到这条消息，点进 AI 表格，看到 AI 给出的修复方案：「参考支付网关 v2.3.0 的超时配置，建议在 PaymentClient.java:128 添加重试策略，预计 30 分钟」。他结合自己的经验判断，觉得方案基本靠谱，但超时时间应该更短。改了参数，40 分钟搞定。CI/CD 跑完，AI 表格自动更新状态，群里推送：
✅ BUG-042 已修复（张三，40 分钟）→ 已部署 staging
这不是假设。用钉钉 AI 表格 + 群沟通 + dws CLI，这个工作流的每个环节今天都能搭出来。下面拆解怎么搭。
上周我写了一篇 LLM 自动化 vs RPA：省的不是智能，是编排成本，提了一个「探索-编译-执行」的三层架构——LLM 先探索网页、找到可行路径，然后编译成代码，后续直接执行。
写完没几天，微软研究院发了 Webwright，几乎就是这套思路的学术验证。但让我意外的不是它验证了三层架构，而是另一个发现： harness 本身可以薄到离谱。
整个系统只有 ~1000 行代码，三个模块，没有 multi-agent 编排，没有复杂的动作空间设计。它给模型的东西只有一个——terminal。
2026 年，深圳的 OPC（一人公司）政策让无数人跃跃欲试。一个有跨境电商经验的运营，配上 Claude Code + Cowork + 几个 AI Agent，就能在两周内搭起一套独立站、自动生成多语言详情页、定时跑竞品分析、自动联系 TikTok 达人。总投入不到 2 万块人民币。
这听起来是梦想照进现实。但亿邦动力最近的一篇调研揭示了一个残酷的侧面：不少跨境卖家用 AI 工具组合自建了工作流，觉得可以替代传统服务商，结果发现「企业是不允许出错的」——AI 在单点任务上表现惊艳，但在需要稳定执行的长链路中，结果波动、环境依赖、交互异常等问题层出不穷。更关键的是： 这些工具解决了执行效率问题，但没有解决方向判断问题。
Anthropic 在今年 5 月发布的一份 34 页创业手册里，有一句判断我反复回味：
上周，一个同事在悟空里问了一句「上周日活多少」，Agent 自信地返回了一个数字：精确到个位，格式漂亮，SQL 语法无懈可击。唯一的问题是——它用了一张已经废弃 3 个月的旧表。
没有人发现这个错误。因为数字「看起来对」。
这就是 Anthropic 在官方博客《How Anthropic Enables Self-Service Data Analytics with Claude》里描述的核心困境。我第一反应是「这不就是自然语言查数吗」。但读完全文，我发现自己错了——Anthropic 真正在做的，不是让业务人员用中文写 SQL，而是把整个数据工程的范式从「给人看」重构为「给 Agent 看」。
Anthropic 原文里最刺痛我的一句话是：
The initial elation of liberation from ad-hoc requests turns into dread with the realization that this setup separates stakeholders from the underlying infrastructure, documentation, and expertise that previously steered them toward carefully curated datasets.
翻译成大白话：你刚把 Claude 接上数据仓库，业务方欢呼终于不用找你写 SQL 了；但很快你会发现，他们问出来的问题越来越离谱，因为 Agent 失去了原来数据团队通过文档、培训、代码审查建立的「认知护栏」。
这不是技术问题，是 数据产品的用户变了。
[Read More]早上九点，我打开电脑，同时启动了三个 AI 任务：让 Claude 审查昨天提交的代码、让 Codex 生成单元测试、让另一个 Agent 整理技术方案文档。一个小时后，三件事都有了初步产出。
要是在两年前，这三件事需要一整个上午，甚至更久。
效率确实提高了。但我发现一个有意思的事情：当我放下 AI 产出物，开始做真正重要的决策——这个架构该不该拆、这个技术路线要不要换、这段代码的设计到底对不对——AI 完全帮不上忙。
这不是 AI 不够好的问题。这是工程效率的本质。
我对 AI 时代工程效率的判断很简单：
本质上只有两件事发生了绝对的变化：
其他方面，还得靠人的品味。
[Read More]上周，两个行业信号先后落地，放在一起看，指向同一个结论。
3 月，Anthropic 宣布投入 1 亿美元建设 Claude Partner Network——不是发更多 API，而是建咨询伙伴体系、认证体系、co-selling 机制。Accenture 培训 30,000 人，Cognizant 覆盖 350,000 员工。这不是技术发布，是交付渠道建设。
5 月，Microsoft 在 Build 2026 把 Agent Governance 做成核心方向——ASSERT 开源评估框架、Agent Control Specification（ACS）开放标准、Agent 365、Foundry Observability。把 Agent 的评估、控制、审计和治理全部产品化。
大多数人还在讨论「谁的模型更强」「谁的 Agent demo 更酷」。但竞争已经换赛道了。
上周五晚上，一个做 RPA 的朋友跟我吐槽：他们给某电商平台搭的自动化流程，上线三个月，页面改版了两次，每次改版都要派人重新录制操作、调整元素定位、测试回归。「甲方觉得 AI 这么火，为什么你们的机器人还是这么脆弱？」
这个问题问得好，但答案可能不是他期望的。
脆弱的不是 AI，是 每次页面变化都要人工重新编排 这个工作模式。影刀、UiPath 这类传统 RPA 工具，本质上是人工录制 + 元素定位的自动化回放。它的优势是稳定——录制好的流程跑一千次都不会出错。它的劣势也很明显——页面改了，流程就废了，而修复的成本和第一次录制一样高。
大模型的 Computer-Use 和 Browser-Use 走了一条完全不同的路，但大多数人只看到了它「贵」和「慢」的一面，没看到它真正值钱的地方。
