历史回顾 · Lesson 01
从 Vibe Coding 到 Agentic Engineering
从 2025 年开始，用双轨时间轴看懂 Coding 模型的发布，如何与 Vibe Coding、Agent、Skills 和工程实践相互推动。
完成后你能：
- 区分模型发布与工具、Agent 工作方式的演进
- 说清 Vibe Coding、Coding Agent、Skills 与 Agentic Engineering 的关系
- 把产品热度与真正的工作方式变化区分开
- 理解为什么能力越强，验证和权限边界越重要
2025 年之前，AI 编程已经经历了补全、聊天和编辑器集成。但这本手册从 2025 年开始，因为这一年发生了一个更重要的变化：模型不再只给建议，它开始在真实的软件环境里采取行动。
这条时间轴不试图记录每次模型升级，也不拿关注度当作能力证明。左侧只保留 DeepSeek、GLM、Kimi，以及 Claude、GPT、Gemini 这六个模型家族中改变 Coding 工作方式的发布；右侧保留改变工作单位、协作接口或责任边界的节点。
TWO TRACKS / ONE SHIFT
模型能力，与行动能力
从模型发布到工具形态，观察 AI 编程如何一步步走向可执行、可复用的工程协作。
模型发布DeepSeek-R1 与开放推理模型推理模型 / 开放权重 / 本地部署
DeepSeek-R1 让更多团队看到：强推理能力不必只存在于一个封闭应用里。模型权重、API 服务与上层工具可以被拆开选择，企业也可以在自己的基础设施中提供兼容接口。
- 为什么重要
- Coding Agent 开始更像一个可替换模型的工作台。保留同一套 OpenCode 工作方式时，管理员可以切换后端模型。
- 留下的问题
- 开放权重或本地部署不自动等于安全。模型能力、服务权限、日志留存和数据边界仍要分别评估。
01- 02
工具 / AgentVibe Coding 被命名自然语言编程 / Accept All / 快速原型
Andrej Karpathy 用“Vibe Coding”描述一种新体验：说出想法，运行 AI 写出的代码，看到问题后继续用语言调整。这个词捕捉到的不是新语法，而是人与代码关系的变化。
- 为什么重要
- 产品、设计和运营人员第一次能直接做出可运行的软件原型。表达意图的能力，开始比记忆 API 更早产生价值。
- 留下的问题
- 原始描述带有“忘掉代码”的轻松意味，适合探索性项目；当软件进入生产，谁来理解风险并对结果负责？
模型发布Claude 3.7 Sonnet：推理进入 Coding 工作流混合推理 / 代码能力 / 长任务
Claude 3.7 Sonnet 把即时回答与可延长的推理放在同一个模型里，并重点展示了代码任务能力。它是这一轮“让模型直接参与工程”的代表性起点。
- 为什么重要
- 模型不再只生成局部代码建议，也开始更适合处理跨文件理解、修改和验证这类需要连续判断的任务。
- 留下的问题
- 更长的推理不会替代验收。模型输出的计划、修改和测试证据仍需要由人或可靠的自动化机制检查。
03工具 / AgentClaude Code 引爆终端 AgentAgentic Coding / 工具调用 / 自动测试
Claude Code 的研究预览把 Agent 放进终端：它能搜索仓库、编辑文件、执行命令、运行测试。工作的基本单位不再是一个函数或代码片段，而是一个带有验收条件的工程任务。
- 为什么重要
- 终端成为 Agent 的通用接口。后续 OpenCode、Codex CLI、Gemini CLI 等工具都强化了“读—改—跑—查”的循环。
- 留下的问题
- 能执行命令意味着能造成真实影响。审批、沙箱、版本控制和最小权限开始成为日常使用的一部分。
- 04
工具 / AgentManus 带火通用 AI AgentGeneral Agent / 虚拟电脑 / 任务交付
Manus 的传播让公众看到另一种 Agent：不是只回答问题，而是在独立环境中浏览网页、整理资料、生成文件并交付结果。Coding Agent 与通用 Agent 的边界开始变薄。
- 为什么重要
- 人们开始按“最终交付物”而不是“回答得像不像人”评价 AI。软件开发也被放进更长的研究、设计和发布链路里。
- 留下的问题
- 长链路任务会累积错误。过程不可见、来源不清楚或无法回滚时，一个漂亮结果并不足以证明任务完成。
模型发布Gemini 2.5 Pro：Thinking 与代码能力结合Thinking model / 代码 / 长上下文
Google 将 Gemini 2.5 Pro 定义为会在回答前推理的 Thinking model，并把复杂推理和代码能力作为核心场景。
- 为什么重要
- 模型厂商开始把“能否完成长链路、工具辅助的任务”作为重要能力，而不是只比较单轮聊天表现。
- 留下的问题
- 长上下文与推理能力能减少中断，却也可能掩盖错误假设；上下文中的资料质量仍决定结果的上限。
05- 06
工具 / AgentCoding Agent 集体爆发CLI / 云端沙箱 / PR Agent
Codex CLI 与云端 Codex、GitHub Copilot Coding Agent、Gemini CLI、OpenCode 等相继受到关注。产品形态逐渐稳定为三类：本地终端协作、云端并行任务、Issue 到 Pull Request 的后台代理。
- 为什么重要
- Agent 不再绑定某一个编辑器或模型。团队开始组合本地反馈速度、云端隔离执行和 GitHub 审查流程。
- 留下的问题
- 产品名称越来越多，但选型不能只看榜单。数据是否出网、能否使用企业模型、如何审查变更更值得优先比较。
- 07
工具 / AgentOpenCode：模型可替换的终端工作台兼容 API / 本地优先 / 工具协议
终端型 Agent 不再只服务于一家模型。以兼容 API 为接口的工具，把模型提供方、执行环境和工程流程拆成可以分别选择的部件。
- 为什么重要
- 这也解释了本教程为何以 OpenCode 与企业兼容 API 为主线：练习的是可迁移的工作流，而不是某个单一产品的按钮。
- 留下的问题
- 可替换不等于无差异。不同模型的上下文、工具调用和安全策略不同，切换后应重新跑关键任务与测试。
模型发布GLM‑4.5 与 Kimi K2：开放权重转向 Agent 任务开源权重 / Coding / Tool use
GLM‑4.5 将推理、代码和 Agent 任务作为一体能力发布；Kimi K2 也以工具调用和自主解决问题为重点。这两次发布让中文开放模型更直接进入 Coding Agent 的可选模型清单。
- 为什么重要
- 企业可以在开源权重、兼容 API 与不同终端工具之间组合，减少工作流对单一闭源模型的绑定。
- 留下的问题
- “开放”不代表部署成本低，也不代表工具调用完全兼容。推理资源、许可证、协议差异和运维能力都要先验证。
08- 09
工具 / AgentAgent Skills 成为新热词SKILL.md / 渐进加载 / 开放标准
Agent Skills 把说明、参考资料与脚本放进一个可发现的目录。Agent 先看到名称和描述，真正需要时才读取完整内容。12 月，Skills 进一步成为跨产品的开放标准。
- 为什么重要
- 关注点从“写一句万能 Prompt”转向“把团队经验变成可测试、可版本化、可共享的能力”。工作方法开始像代码一样被维护。
- 留下的问题
- Skill 可能包含脚本和外部依赖。安装社区 Skill 前，必须检查它会读取什么、运行什么、连接哪里。
模型发布DeepSeek‑V3.2：面向 Agent 的开放模型继续迭代开放模型 / 推理优先 / Agent
DeepSeek 在 12 月发布 V3.2。官方将其列为面向 Agent 的推理优先模型，显示开放模型的竞争重点已从一般对话扩展到工具使用和复杂任务。
- 为什么重要
- 对团队而言，模型评估开始同时看推理、代码、工具调用与运行成本，而不是只看单一聊天体验。
- 留下的问题
- 公开发布并不能替代内部评测。涉及企业代码时，还需确认部署方式、数据流和实际任务上的稳定性。
10- 11
工具 / AgentOpenClaw 与长期运行 Agent常驻 Agent / 持久记忆 / 消息渠道
OpenClaw 从 Clawdbot、Moltbot 更名后迅速传播。它通过消息应用接受任务，连接浏览器、文件、邮件和日历，并能持续运行。Agent 从一次 coding session 扩展成了个人计算环境的一部分。
- 为什么重要
- Skills、记忆、定时任务和多渠道连接组合到一起，展示了“自己的 Agent”可以是什么样子。
- 留下的问题
- 常驻 Agent 拥有更长时间和更大权限，也更容易受到 Prompt Injection、凭证泄露和错误自动化影响。
模型发布Claude Opus 4.6：更长时间的 Agentic Coding代码审查 / 调试 / 1M 上下文
Anthropic 在 Claude Opus 4.6 发布中明确强调：它能更仔细地规划，在更大代码库中持续执行 Agent 任务，并改进代码审查和调试。
- 为什么重要
- 闭源前沿模型的重点从“写出一段代码”进一步转向在大型工程中保持任务连续性和自我纠错。
- 留下的问题
- 持续执行时间越长，越需要把权限、停止条件和可回滚的中间产物设计进工作流。
12- 13
工具 / AgentMulti-Agent 与 Agentic Engineering并行 Agent / Worktree / 自动化 / 监督
Codex App 等产品开始让用户同时指挥多个 Agent，在隔离 worktree 中并行工作。讨论也从 Vibe Coding 走向 Agentic Engineering：不再只强调表达想法，而是强调任务拆解、约束、测试和审查。
- 为什么重要
- 人的主要工作从逐行输入代码转向定义问题、设计接口、判断证据和承担最终责任。
- 留下的问题
- 并行并不会自动提高质量。没有清晰边界的多 Agent，只会更快地产生冲突、重复和不可审查的修改。
模型发布DeepSeek‑V4：兼容接口进入新一代开放模型V4‑Pro / V4‑Flash / OpenAI 与 Anthropic 兼容
DeepSeek 在 4 月发布 V4，并提供 V4‑Pro 与 V4‑Flash。官方 API 同时支持 OpenAI Chat Completions 与 Anthropic 接口，模型的替换成本继续下降。
- 为什么重要
- 对终端 Agent 使用者来说，模型竞争不只发生在能力榜单，也发生在是否能以较小迁移成本接入现有工作流。
- 留下的问题
- 协议兼容解决了接入问题，却不能保证行为一致；切换模型后，哪些关键任务必须重新评测？
14模型发布Claude Fable 5：长周期 Coding Agent长任务 / 子 Agent / 自我测试
Anthropic 将 Claude Fable 5 定位为可处理数日复杂、异步任务的第五代模型，并明确把软件工程、Claude Code 与多 Agent 协作作为主要使用场景。
- 为什么重要
- 模型能力的讨论从“能不能写出来”进一步转向“能否在较少监督下持续完成大工程”，也让停止条件、审查和安全护栏变得更关键。
- 留下的问题
- 一个可运行数日的 Agent，何时应该自主推进，何时必须停下来等待人的审批？
15模型发布GLM‑5.2：为长周期工程任务而生1M 上下文 / Coding Agent / MIT 开源
Z.AI 在 6 月发布 GLM‑5.2，重点是可稳定维持长周期任务的 1M 上下文、可调节的推理强度，以及面向 Coding Agent 的能力；模型同时提供 MIT 开源许可。
- 为什么重要
- 它把“长上下文”从参数竞争拉回真实工程轨迹：长任务能否持续保持代码、工具调用与调试质量，才是 Agent 实用性的关键。
- 留下的问题
- 上下文窗口变大后，团队怎样避免把无关资料和历史错误一起带进 Agent 的长期轨迹？
16模型发布GPT‑5.6：模型族直接进入 CodexSol / Terra / Luna / ChatGPT / Codex / API
OpenAI 在 7 月正式发布 GPT‑5.6 系列：旗舰 Sol、均衡的 Terra 与高效的 Luna，并同时提供给 ChatGPT、Codex 和 API。
- 为什么重要
- Coding 工作流开始更明确地按任务难度、成本与所需推理强度选择模型，而不是固定使用同一个旗舰。
- 留下的问题
- 当同一家提供多档模型时，团队如何定义升级策略、成本上限与回归评测？
17模型发布Kimi K3：开放前沿模型走进 Kimi Code开放前沿 / Kimi Code / API
Moonshot 在 7 月发布 Kimi K3，并把它提供到 Kimi、Kimi Work、Kimi Code 与 Kimi API。官方将其定位为开放前沿智能模型，也把 Coding 放进主要评测与使用场景。
- 为什么重要
- 它让 2026 年的模型竞争更清楚地呈现为：闭源模型继续拉长自主任务，开放模型同时追赶代码、上下文和工具调用能力。
- 留下的问题
- 模型开放后的真正门槛在哪里：权重、推理资源、服务容量，还是适配工具链和安全治理的能力？
18
Token 的流向：从聊天消耗到工程负载
Token 不是生产率的同义词：它会受模型、价格、上下文长度、缓存和产品策略影响。但它能回答另一个更基础的问题：真实工作是否已经从零散对话，迁移到了需要读取代码库、调用工具并反复验证的长链路任务？公开路由数据和 Claude Code 的内部使用数据，给出了相同方向的信号。
| 观察窗口 | 可核对的数据 | 它说明什么 |
|---|---|---|
| OpenRouter 公开流量 | OpenRouter 与 a16z 对超过 100 万亿 token 的真实交互做了研究；编程请求的 token 占比从 2025 年初约 11% 升至研究期末的 50% 以上。编程请求的输入上下文通常超过 20K token。 | Coding 已经不是“偶尔让模型补一段代码”。模型正在持续读取更大的代码、文档和历史上下文，承担调试、理解与生成组成的工作负载。 |
| Claude Code 外部真实使用 | Anthropic 对 2025 年 10 月至 2026 年 4 月约 40 万个 session、23.5 万名用户 的分析显示，56% 的 session 直接用于写代码、修复代码、测试或编排；一次用户指令平均触发约 10 次 Claude 行动。 | Agent 的基本单位已是“给一个目标，再让它读—改—跑—查”，而不再是单次问答。 |
| Claude Code 在 Anthropic 内部 | Anthropic 对 20 万份 内部 Claude Code transcript 的比较发现，连续工具调用从 9.8 次增至 21.2 次（+116%），每个 transcript 的人工轮次从 6.2 降至 4.1 次（-33%）。同一项内部调研中，员工自报 Claude 已覆盖约 59% 的日常工作，并带来约 50% 的生产率提升；这是自报结果，不应当外推为所有团队的因果结论。 | 当能力、上下文和工具链共同改进时，人不必频繁把执行拆成小指令；人的注意力可以转向目标、边界、验收与异常处理。 |
数据口径并不相同：OpenRouter 是单一平台的聚合 token 流量，Anthropic 数据包含内部样本与自报调查，不能相加，也不能直接代表整个行业。但它们共同否定了一个旧印象：AI Coding 只是写得更快一点。更大的上下文、更长的执行链和更少的人工微操作，说明软件生产的执行层正在被重新组织。
来源：OpenRouter《State of AI》、Anthropic：Claude Code 的实际使用、Anthropic：AI 如何改变内部工作。
飞轮已经转起来了，工作单位也在变大
观点：飞轮已经转起来了。 更强的模型让 Agent 能完成更长的工程任务；更长的任务产生更多真实的代码、测试、日志和使用反馈；这些反馈又让模型、工具协议、Skills 与评测更贴近生产环境。AI Coding 不再只是“更快写代码”，而是在降低尝试、验证和跨领域协作的成本，开启一次巨大的生产力提升。
这个飞轮最明显的结果，是 AI 的工作单位不断变大：代码补全时代是一行代码；Vibe Coding 把它扩大为一个可见效果；Claude Code 等工具又把它扩大为一个工程任务；Skills 让一套完成任务的方法能够复用；OpenClaw 和多 Agent 产品则让任务跨越应用、设备和时间。
工作单位越大，人越不可能通过“盯着每一个字符”控制质量，必须把测试、审查、权限和回滚放进同一个闭环。飞轮转得越快，越要升级控制方式：
- 在开始前写清目标、限制和验收标准；
- 把大任务切成可以独立验证的小任务；
- 让 Agent 展示计划、差异、命令和测试结果；
- 给高风险动作设置审批与最小权限；
- 用 Git、测试和日志保留回退与追溯路径。
否则，被放大的也会是错误。
从“忘掉代码”到“对结果负责”
Vibe Coding 的价值是真实的：它让更多人能够直接把想法做成东西。它的风险也同样真实：自然语言看起来简单，却可能隐藏模糊需求；生成速度很快，却可能让审查和理解跟不上。
因此，本教程不会把 Vibe Coding 与工程纪律放在对立面。我们保留它快速探索、即时反馈的优势，再加入计划、测试、版本控制和安全边界。你可以不亲手输入每一行代码，但必须能够回答：
- 这次修改要解决什么问题？
- Agent 改了哪些文件，为什么？
- 什么证据表明它真的可用？
- 出错时如何回到上一个安全状态？
- 哪些信息和权限绝不能交给它？
这就是从“感觉正确”走向 Agentic Engineering 的起点。