AGI 进入“执行系统战争”：我对 OpenAI、Anthropic 与开发者新工种的判断#

过去一年我最明显的体感是：AGI 讨论终于从“模型参数和榜单”转向“谁能稳定交付结果”。

如果只看热闹，今天最容易刷到的是新模型名字；但如果真在一线做产品、做自动化、做工程团队提效，你会发现真正的分水岭是另一件事：

AGI 正在从“会回答问题的模型”，变成“可运营的执行系统”。

这篇我想讲三件事：

我眼里 OpenAI 和 Anthropic 这两条供给侧路线正在如何收敛。
为什么“造 AGI”这件事，开始倒逼“做 AGI”的开发者重写自己的工作方式。
接下来 12-24 个月，我认为开发者最该押注的能力栈是什么。

1) 供给侧已经不是“更聪明”竞赛，而是“更可部署”竞赛#

从公开信号看，OpenAI 和 Anthropic 都在做同一件底层工程：

更强推理与更长上下文，服务长链路任务。
更稳定工具调用，减少 agent workflow 里的断点。
更明确安全与治理边界，把“能力增长”放进可监管、可审计框架。

例如 OpenAI 在 2025 年底发布 GPT-5.2，公开强调 long-running agents、工具调用和专业工作场景的端到端性能，而不是单点 benchmark 的漂亮数字（来源：OpenAI 发布说明）。

Anthropic 这边，一个值得关注的信号是它把“真实使用行为”拿出来做经济分析：在 2026 年 3 月 Economic Index 里，编码任务继续向 API 侧迁移、自动化工作流占比变化、以及“高资历用户成功率更高”的学习曲线都很清晰（来源：Anthropic Economic Index, March 2026）。

我自己的结论很直接：

下一阶段的护城河不是某个瞬时模型分数，而是把模型能力变成“持续可用生产力”的系统能力。

这解释了为什么“做 AGI”的公司越来越像在做“云 + 编译器 + 调度系统 + 安全体系”的混合体。

2) “做 AGI”与“造 AGI”正在形成双螺旋#

我把这两件事分开看：

做 AGI：OpenAI、Anthropic 这类供给侧，负责把模型能力、工具接口、安全边界不断前推。
造 AGI：开发者、产品团队把这些能力组装成能交付结果的业务执行系统。

过去很多团队把 AI 当“外挂问答”；现在我看到更高效的团队，已经把 AI 当“执行层员工”，并围绕它设计：

可回放的任务日志
明确的审批节点
自动重试与降级策略
任务分解与子代理编排
成本、时延、正确率三者的实时观测

这意味着开发者角色在变：

以前你主要写业务逻辑；现在你越来越像在设计一个“人类 + agent + 工具链”的混合操作系统。

3) 开发者未来形态：从“写函数的人”到“设计执行系统的人”#

如果我给未来两年的技能栈排优先级，会是下面这个顺序：

A. 工作流工程（Workflow Engineering）#

能把一个含糊目标拆成稳定可执行的多步流程，定义每一步的输入、输出、失败处理和回滚。

B. Agent 可观测性（Observability）#

不是只看 token 成本，而是看任务成功率、重试路径、工具失败热点、人工接管点。

C. 评测与护栏（Evals + Guardrails）#

为关键任务建立持续评测集，配合策略护栏和权限隔离；让系统在“足够聪明”的同时“可控可解释”。

D. 人机协作界面（Human-in-the-loop UX）#

未来高价值产品不只是“自动化”，而是“自动化 + 可审阅 + 可接管”。

E. 经济性优化（Cost/Latency/Quality）#

真正的工程成熟，不是把最贵模型塞满全流程，而是做模型路由、预算控制、分层推理。

一句话总结：

未来最稀缺的开发者，不是会不会调一个模型 API，而是能把模型变成组织执行能力的人。

4) 我现在的实践原则#

我自己最近在项目里坚持三条规则：

先定义“可交付结果”，再定义 prompt。
先搭评测和回放，再追求更高自动化率。
先把失败路径做短，再谈规模化。

这样做的收益很现实：

团队对 AI 的信任来自可验证结果，而不是 demo 时刻。
开发节奏从“模型更新驱动”转为“业务结果驱动”。
每次模型升级都能被快速吸收，而不会重写整套系统。

5) 结语#

AGI 时代真正的热点，不是“谁先喊出 AGI”，而是“谁先把 AGI 变成稳定产能”。

OpenAI、Anthropic 在供给侧加速“做 AGI”；开发者在需求侧加速“造 AGI”。

这不是两条平行线，而是一条不断互相强化的双螺旋。

我对未来的判断没有那么浪漫：它会先成为工程问题，再成为哲学问题。

而我们这代开发者的机会，也恰好在这里。