Agentic Engineering（代理工程化）是把 AI 编码工具纳入工程治理体系的生产级范式——人类担任架构师与评审者、由多智能体在受控工作流中执行实现，目标是保留 AI 写代码的速度同时把质量门禁、合规审计与可维护性补齐。Vibe Coding 则是同一时期的另一端：用自然语言描述意图、接受 AI 输出而不逐行阅读，胜在原型速度、败在生产治理。理解这两个概念的分界，决定了一支团队交付的软件能不能经得起长期演进。
一、概念溯源：Karpathy 在两年里定义的两个范式
“vibe coding” 由前特斯拉 AI 总监 Andrej Karpathy 在 2025 年 2 月提出，原意是”完全沉浸在感觉中，让 AI 生成代码而不仔细读 diff”。这个略带调侃的定义迅速走红，并被柯林斯词典列为 2025 年度词汇。
随着 2025 年 Claude Code、Codex CLI、Gemini CLI 等代理型工具的成熟，Karpathy 在 2026 年初又提出 “agentic engineering”——核心思想是”代理编排 + 人类把关”。在 IBM、Anthropic 等机构的同步论述里，这两个词不是同义词的不同写法，而是软件工程在 AI 时代的”原型范式”与”生产范式”分野。
二、五维对比：把”差别”拆开看
两类范式的差别集中在五个维度。下表先给结论，再展开解释。
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 人类角色 | 需求方、接受输出 | 架构师、评审者、把关人 |
| 代码理解 | 不必逐行阅读 | 必须理解架构与关键逻辑 |
| 质量门禁 | “能跑就上” | 自动化测试 + 人工评审 + 架构校验 |
| 规模 | 原型、个人项目 | 生产系统、团队协作 |
| 风险管控 | 低（一次性项目） | 高（人类兜底+可追溯） |
展开看几个容易被忽略的差异：
- 责任归属：Vibe Coding 出问题时往往无法定位”是谁的代码”；Agentic Engineering 要求所有 PR 走与人类代码相同的评审流程。
- 可审计性：监管行业（金融、医疗）需要追溯每一行代码的来源、审批人与规范，Vibe Coding 没有原生答案。
- AI 角色定位：Vibe Coding 把 AI 当成”代码生成器”；Agentic Engineering 把 AI 当成”在受控工作流里执行多步任务的代理”。
三、Agentic Engineering 的四大核心原则
从工业界 2025-2026 年的实践看，Agentic Engineering 可拆成四条原则，缺一就会退化为 vibe coding。
- 人做架构、AI 做执行：人类定义系统设计、数据模型、API 接口，AI 负责 CRUD、测试用例、文档样板这类 95%~99% 的实现量。
- 多代理协作而非单一助手：编码代理、测试代理、文档代理、评审代理各司其职，每个都被约束在明确的能力域内。
- 确定性质量门禁：CI/CD 里嵌入自动 lint、单元测试、安全扫描；架构变更必须由资深工程师签字才能合并。
- 结构化反馈循环：需求 → 生成 → 评审 → 修订 → 合入，循环式迭代而非单次”提示-回答”。
这四条在 Karpathy 的原话里被进一步拆成两个关键词：”Agentic”强调代理编排 + 人在回路（human-in-the-loop），”Engineering”强调使用代理所需的专业能力——后者是可以通过训练获得的技能。
四、典型工作流与代码骨架
Agentic Engineering 的落地形态通常以”规范驱动开发（Spec-Driven Development）”为核心：先写结构化需求规范（spec），再让代理按规范生成代码与测试，最后由人类评审合入。下面给出一段伪代码，体现”规范—执行—校验”的最小闭环：
# Agentic Engineering: 规范驱动的最小闭环
spec = {
"feature": "用户登录",
"inputs": {"username": str, "password": str},
"outputs": {"token": str, "expires_in": int},
"errors": ["INVALID_CREDENTIALS", "RATE_LIMITED"],
}
# 1. 编码代理按 spec 生成实现
code = coding_agent.generate(language="python", spec=spec)
# 2. 测试代理根据 spec 自动生成测试用例
tests = testing_agent.generate(spec=spec, framework="pytest")
# 3. 评审代理做架构/安全/合规检查
report = review_agent.check(code, rules=ARCH_RULES + SEC_RULES)
if report.has_blocking_issue:
raise ReviewFailed(report.summary) # 人类再介入
# 4. 人工 review、合入主干
human_approve(pr=code + tests, reviewer="senior_engineer")
merge_to_main()这段代码解决的核心问题是”AI 输出没有边界”——vibe coding 的失败模式就是缺少这段前置 spec 与后置 review。执行前要先做规范评审，避免代理把错误的接口形态当成需求；执行后要看评审代理的报告与人工签字记录，没有这些审计痕迹就退化成 vibe coding。
五、工具栈与选型建议
2026 年主流工具链已经基本收敛。Claude Code（Anthropic）在多文件、长上下文与 Git 集成上领先，适合复杂仓库的重构；Codex CLI（OpenAI）交互更轻，适合脚本化任务；Gemini CLI（Google）的优势在多模态，可以直接处理图像与音频。Rakuten 工程团队曾用 Claude Code 在 7 小时内完成 vLLM 1250 万行代码的激活向量提取功能实现，是 Agentic Engineering 在大型开源项目落地的代表案例。
中小团队落地的最小可行组合：Claude Code 或 Codex CLI 一个 + CI 里强制跑测试 + 强制 code review。这套组合成本最低、回退最容易。
六、什么时候该选哪种范式
不是所有项目都需要 Agentic Engineering 那一套。判断标准很直接：代码出错的后果有多严重？
- 原型、个人项目、一次性脚本、hackathon → vibe coding 更快。
- 需要长期维护、合规审计、团队协作的生产系统 → 选 Agentic Engineering。
- 边界场景（如内部工具但要长期运行）→ 用 Vibe Coding 起量，但至少补上 spec 与 review 两道工序。
Stack Overflow 2025 开发者调查显示，84% 的开发者已经在用 AI 辅助编程，但只有 3% “高度信任” AI 输出。这组数据说明：行业共识已经偏向 Agentic Engineering 那侧——AI 写代码没问题，关键在治理框架。
到这里，vibe coding 与 agentic engineering 的边界就清晰了：差别不是”用不用 AI”，而是”用 AI 时有没有工程治理”。前者是工具，后者是纪律。
常见问题（FAQ）
Q1：Agentic Engineering 会取代软件工程师吗？
不会。它把工程师从样板代码里解放出来，把精力集中到架构、安全、业务建模等高杠杆决策上。
Q2：小团队有必要上多代理吗？
不必。单一编码代理 + CI 测试 + 强制 review 已能覆盖大多数生产场景；多代理适合大型仓库或复杂业务。
Q3：如何识别一个团队在做 vibe coding 还是 agentic？
问三个问题：有没有 spec？AI 代码是否走正常 PR 流程？幻觉出的 API 调用如何兜底？答不上来的基本是 vibe coding。
