Agentic Engineering 范式转移：从 Vibe Coding 到系统化 AI 开发¶
Google 上线了一套 5 天的 AI 开发课程，第一次把业界正在收敛的共识写成正式框架。这份笔记覆盖 Day 1 的核心：vibe coding 到 agentic engineering 的光谱、context engineering、Agent = Model + Harness 公式，以及 token 经济学。适合想建立完整 AI 开发心智模型的工程师和技术管理者。
目录¶
- #1. 范式转移：从 Vibe Coding 到 Agentic Engineering
- #2. 核心技术杠杆：Context Engineering
- #3. 开发流程与架构重建：Harness Engineering
- #4. 人类角色转变与 Token 经济学
- #5. 核心价值提炼与行动建议
- #参考资料
- #相关笔记
1. 范式转移：从 Vibe Coding 到 Agentic Engineering¶
核心概念¶
Vibe Coding（凭感觉编码）：Andrej Karpathy 提出的概念，以自然语言描述需求，遇 Error 直接复制报错让 AI 修正。适合快速验证概念/Prototype，但在复杂系统或商业级应用中易产生不可维护的代码。
Agentic Engineering（代理工程）：在明确边界内让 Agent 自我诊断与修正，配合 Spec 架构文件、自动化测试（CI/CD Gates）与 LLM Judges 的系统化开发模式。
AI 开发光谱（三位一体）¶
Google 将 AI 辅助开发定义为连续光谱，而非非黑即白的开关：
| 维度 | Unstructured / Vibe Coding | AI-Assisted Coding | Agentic Engineering |
|---|---|---|---|
| Prompt 方式 | 口语 Prompt、凭感觉 | 具备一定结构 | 明确的 Spec 架构文件 |
| 验证机制 | 看起来会动即通过 | 部分辅助工具 | CI/CD Gates + LLM Judges |
| 错误处理 | 重复喂错误讯息给 AI | 人工+AI 协同 | Agent 自我诊断与修正 |
| 适用场景 | 快速验证概念、Prototype | 日常开发 | 商业级应用、复杂系统 |
| 可维护性 | 低（代码面条化） | 中 | 高 |
验证（Validation）双柱——分水岭¶
区隔光谱两端的关键在于验证机制：
| 验证类型 | 验证对象 | 性质 | 说明 |
|---|---|---|---|
| Test（测试） | Code 的输入输出 | 确定性 | 验证代码是否符合预期 |
| Evals（评估） | Agent 的工具选择、路径规划、产出品質 | 非确定性 | 评估 Agent 行为是否达标 |
ASCII 流程图：验证分水岭¶
AI 辅助开发
┌─────┴─────┐
Vibe Coding Agentic Engineering
│ │
无系统验证 系统化验证
│ ┌──────┴──────┐
"看起来会动" Test Evals
(确定性) (非确定性)
代码输入输出 Agent 行为评估
2. 核心技术杠杆：Context Engineering¶
核心概念¶
Context Engineering（脉络工程）比 Prompt Engineering 更关键。Prompt Engineering 仅是单次对话的精雕细琢；Context Engineering 则是为 AI 提供完整的"入职简报"与运作环境，是系统级能力。
Context 的六大构建要素¶
| 要素 | 英文 | 说明 | 示例 |
|---|---|---|---|
| 指令 | Instructions | 定义角色与行为边界 | System Prompt、角色设定 |
| 知识 | Knowledge | 领域专门知识 | API 文档、业务规则 |
| 记忆 | Memory | 长短期状态记录 | 对话历史、用户偏好 |
| 案例 | Examples | 示范案例 | Few-shot examples |
| 工具 | Tools | 可呼叫的外部工具定义 | Function calling、MCP 服务 |
| 护栏 | Guardrails | 硬性约束规范 | 安全边界、禁止行为 |
Static Context 与 Dynamic Context 的架构取舍¶
这是 Context Engineering 最核心的架构决策：
| 维度 | Static Context | Dynamic Context |
|---|---|---|
| 载入时机 | 每次对话必定载入 | 按需载入（Pay-as-you-go） |
| 典型载体 | AGENT.md、.cursorrules |
Agent Skills、RAG 检索、工具返回结果 |
| 可靠性 | 高（必定存在） | 中（Agent 需主动调用） |
| Token 成本 | 高（每次都消耗） | 低（按需付费） |
| 扩充性 | 低（载入过多会撑爆窗口） | 高（可挂载数十种） |
| 核心风险 | 成本膨胀 | Agent 未主动调用 |
判断决策树：Static vs Dynamic¶
这个 Context 是否每次都需要？
├── 是，且不可妥协
│ └── → Static Context（AGENT.md / .cursorrules）
│ 代价：每次 Token 消耗
│
└── 否，按场景才需要
└── → Dynamic Context（Skill / RAG）
代价：Agent 可能不调用
缓解：Progressive Disclosure
Progressive Disclosure（渐进式揭露）¶
Agent 启动时仅读取 Skills 的 Metadata（中继资料），当任务匹配时才载入完整指令。这让 Agent 能拥有数十种专长，同时维持极低的运作成本。
Agent 启动
│
▼
读取所有 Skills 的 metadata（低成本：仅标题+描述）
│
├── 任务 A 匹配 Skill #3 → 载入 Skill #3 完整指令
├── 任务 B 匹配 Skill #7 → 载入 Skill #7 完整指令
└── 其他 Skills → 不载入（省 Token）
实际应用：Hermes Agent 的 Skill 系统正是此模式——启动时只载入 SKILL.md 的 frontmatter（名称+描述），匹配到任务时才 skill_view 载入完整内容。
3. 开发流程与架构重建：Harness Engineering¶
软件工厂模型（Software Factory Model）¶
传统 SDLC 的编码阶段被剧烈压缩，工程师角色转变为"工厂经理"——主要产出不再是代码本身，而是生产代码的"系统与产线"。
传统模式: 软件工厂模型:
┌────────────┐ ┌──────────────────────┐
│ 工程师 │ │ 工程师 = 工厂经理 │
│ ↓ 写代码 │ │ ↓ 建产线（系统） │
│ 代码 │ │ 产线 → 批量产出代码 │
└────────────┘ └──────────────────────┘
产出: 代码行数 产出: 生产代码的系统
价值: 与时间线性 价值: 复利（产线可复用）
核心公式：Agent = Model + Harness¶
┌─────────────────────────────────────────────┐
│ Agent (完整代理) │
│ │
│ ┌─────────────┐ ┌─────────────────┐ │
│ │ Model │ + │ Harness │ │
│ │ (底层模型) │ │ (配置框架) │ │
│ │ │ │ │ │
│ │ GPT/Claude │ │ Rules + Tools │ │
│ │ Gemini 等 │ │ + Sandbox │ │
│ │ │ │ + Orchestration │ │
│ │ (会随时间 │ │ + Hooks │ │
│ │ 不断汰换) │ │ + Observability │ │
│ └─────────────┘ └─────────────────┘ │
│ │
│ 多数 Agent 失败 ≠ 模型不够聪明 │
│ 多数 Agent 失败 = 配置缺陷（Harness 有问题） │
└─────────────────────────────────────────────┘
关键洞察：单靠模型升级无法解决系统性问题。底层模型会随时间不断汰换，但投资在 Harness、Skills 及 Evals 规范是可被版控且能产生复利效益的真实资产。
Harness 的六大核心构件¶
| 构件 | 说明 | 典型实现 |
|---|---|---|
| Rule Files | 核心原则与约束边界 | AGENT.md、.cursorrules |
| Tools | Functions 与 MCP 服务 | Function calling、MCP servers |
| Sandbox | 安全隔离的执行环境 | Docker、代码沙箱 |
| Orchestration | 多 Agent 调度与路由交接 | 多 Agent 编排框架 |
| Hooks | 生命周期中的确定性代码 | Git Commit 前的自动金钥检测 |
| Observability | Trace、Log、Evals 与成本监控 | 链路追踪、日志、成本看板 |
最佳实践¶
- ✅ 将 Harness（System Prompt、Skills、Hooks、Evals）纳入 Git 版控与 Code Review
- ✅ 每一次 AI 发生的错误都转化为新的 Rule 约束条款（错误即资产）
- ✅ Harness 是可复利的资产，模型是消耗品
- ❌ 不要指望换更强的模型来解决 Harness 的配置缺陷
- ❌ 不要把 Harness 配置当作一次性设定，应持续迭代
4. 人类角色转变与 Token 经济学¶
人类开发者的双模切换¶
| 模式 | Conductor（指挥家） | Orchestrator（编排者） |
|---|---|---|
| 场景 | IDE 中即時监控 | 派发背景任务 |
| 关注粒度 | 每一行 Code 的生成 | 大规模平行变更 |
| 适合任务 | 复杂逻辑、Debug | 任务拆解、规格制定、品质评估 |
| 交互方式 | 即时、同步 | 异步、平行 |
| 核心能力 | 代码审查、逻辑判断 | Decomposition、Specification、Evaluation |
开发者双模切换:
┌──────────────────┐ ┌──────────────────┐
│ Conductor │ ←──→ │ Orchestrator │
│ (指揮家) │ 切换 │ (編排者) │
├──────────────────┤ ├──────────────────┤
│ IDE 即时监控 │ │ 派发背景任务 │
│ 逐行审查代码 │ │ 平行处理大规模变更 │
│ 适合: 复杂逻辑 │ │ 适合: 任务拆解 │
│ Debug │ │ 规格制定 │
└──────────────────┘ └──────────────────┘
Token 经济学：CapEx 与 OpEx 的财务杠杆¶
这是决定长期成本的核心分析框架：
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 前期 CapEx（资本支出） | 低（直接开始写） | 高（建置 harness、测试、规格） |
| 后期 OpEx（营运支出） | 高且持续上升 | 低且边际递减 |
| Token 燃烧率 | 高（反复试错） | 低（一次通过率高） |
| 维护难度 | 高（代码面条化） | 低（结构化、可测试） |
| 资安风险 | 高（需事后补救） | 低（Hooks 前置防护） |
| 一次通过率（First-pass accuracy） | 低 | 高 |
ASCII 流程图：Token 经济学的时间轴¶
成本
│
│ Agentic Engineering
│ ┌──────────────┐ ← 前期 CapEx 高
│ │ │
│ │ ╲
│ │ ╲___ ← OpEx 边际递减
│ │ ──────────
│ │
│ ──────┘ 时间 →
│
│ Vibe Coding
│ ┌──┐ ← 前期 CapEx 低
│ │ ╲
│ │ ╲___
│ │ ╲
│ │ ╲___ ← OpEx 持续上升
│ │ ╲ ╲
│ │ ╲ ╲___ (维护+资安补救)
│ └─────────────────────────
│
└────────────────────────────── 时间 →
交叉点之后，Agentic Engineering 的总成本优势持续扩大
判断决策树：何时该投资 Agentic Engineering¶
你的项目是什么性质？
├── 一次性 Prototype / Demo
│ └── → Vibe Coding 足够（CapEx 投资不划算）
│
├── 需要长期维护的产品
│ └── → Agentic Engineering（OpEx 复利效应显著）
│
├── 团队协作项目
│ └── → Agentic Engineering（Harness 可版控、共享）
│
└── 商业级/企业应用
└── → 必须用 Agentic Engineering（资安、可维护性要求）
5. 核心价值提炼与行动建议¶
一句话核心价值¶
"Generation is solved. Verification, judgment, and direction are the new craft." （代码生成已被解决。验证、判断与方向，才是新的手艺。）
程式碼生成的效率問題已被 LLM 解決，未來的軟體工程核心競爭力在於規格定義、驗證機制、架構判斷與系統轉向。
个人开发者行动建议¶
| 行动 | 说明 | 对应概念 |
|---|---|---|
建立并维护 AGENT.md |
将每次 AI 错误转化为新的约束条款 | Static Context / Rule Files |
| 实施测试先行 | 生成代码前先写测试与 Evals | Validation 双柱 |
| 保留重塑与 Review 基础功 | 不盲目信任生成结果 | Conductor 模式 |
| 投资可版控的资产 | Skills、Hooks、Evals 纳入 Git | Harness = 复利资产 |
团队与企业主管行动建议¶
| 行动 | 说明 | 对应概念 |
|---|---|---|
| 视为系统工程投资 | 非单纯购买 Tool 订阅 | Software Factory Model |
| Harness 纳入版控 | System Prompt、Skills、Hooks、Evals 进入 Code Review | 可复利资产 |
| 调整人才标准 | 从"纯手动编码"转向"系统设计、任务拆解、品质判断" | Orchestrator 角色 |
参考资料¶
- Google Kaggle 5-Day AI Agents: Intensive Vibe Coding Course — 课程主页
- Kaggle 课程讨论区：Day 1 Assignment — 学员讨论与白皮书要点
- KDNuggets: Kaggle + Google's Free 5-Day Agentic AI Course — 课程概览与评价
- 原始视频：15 分鐘看完 Google Vibe Coding/Agentic Engineering 開發課 Day 1 — Gary Chen 频道
- Patreon 完整文章与提示词模板 — 付费内容（预览可见大纲）
相关笔记¶
- [[Context Engineering 实践]]
- [[Hermes Agent Skill 系统]]
- [[MCP - Model Context Protocol]]
- [[AI Agent 架构模式]]