AI领域的各种Engineering是什么意思？

2025 年初 Andrej Karpathy 发了一条推文，把"让 AI 随便写代码"命名为 Vibe Coding。一年后这个词被写进维基百科；又过了一年，业界开始批判它"只管生、不管养"。与此同时，SDD、Harness Engineering、Loop Engineering、Graph Engineering、Coordination Engineering 这些新名词你方唱罢我登场。它们之间到底是什么关系？哪一个是真正的下一代，哪一个是营销包装？

一条主线：瓶颈在往外移

AI 工程范式的演进有一个清晰规律：每当模型能力过线，瓶颈就从模型本身向外层转移一层。

2023 年大家卷提示词，因为模型第一次能听懂复杂指令；2025 年发现提示词写得再好，模型看不到关键上下文也白搭，于是 Context Engineering 兴起；2026 年又发现上下文给对了，环境约束不对照样翻车，于是 Harness 成为热点；到了 2026 年中，单智能体循环再精致也扛不住复杂任务，于是多智能体编排和图结构成为新战场。每一次转移都不是否定前一层，而是把前一层的成果纳入更完整的体系。

时间线：从 RAG 到 Graph Engineering

2020.12 — RAG：给模型接外脑

Facebook AI 的 Patrick Lewis 等人提出 Retrieval-Augmented Generation，让模型生成前先检索外部知识。这是企业知识库、文档问答的底层范式。

2022.11 — ChatGPT：对话式 AI 爆发

大模型从实验室进入大众视野，AI 编程从"代码补全"走向"对话式生成"。

2023 — Prompt Engineering + Copilot 普及

"怎么写提示词"成为第一课，GitHub Copilot 让 AI 辅助编码成为日常。

2024.11 — MCP：工具接口标准化

Anthropic 发布 Model Context Protocol，试图像 USB-C 一样统一 AI 与外部工具、数据的连接方式。2025 到 2026 年被 Cursor、Claude Code 等大量采用。

2025.02 — Vibe Coding：Karpathy 的"氛围编程"

用自然语言描述需求，全盘接受 AI 生成代码。门槛极低、Demo 极快，但维护成本极高——“没人知道代码在做什么”。

2025 年中 — Context Engineering：从"怎么写"到"给什么"

Karpathy 公开支持 Context Engineering 取代 Prompt Engineering。关注点变成代码库上下文、Git 历史、依赖关系、检索文档等"模型看到的信息环境"。

2025-2026 — SDD：规范驱动开发

作为 Vibe Coding 的反面出现：先写 Spec，再让 AI 按规范生成。OpenSpec、Spec Kit、BMAD 等工具相继出现；2026 年 6 月 LG CNS 与 Cline 发布企业级 Spec Driven 平台，腾讯 CodeBuddy SPEC 模式也获得工程圈认可。

2026.02 — Harness + Agentic Engineering

Mitchell Hashimoto 提出 Harness Engineering，OpenAI 用"3 人 5 个月零手写代码交付百万行"引爆；Karpathy 同阶段提出 Agentic Engineering，主张"99% 时间不再直接写代码"。

2026.04 — Coordination Engineering：openJiuwen 的"协同工程"

华为支持的 openJiuwen 社区发布 JiuwenClaw，将 Harness Engineering 的"下一跳"定义为 Coordination Engineering，聚焦多智能体团队编排、任务调度、通信协议与经验沉淀。

2026.06 — Loop Engineering：单智能体自循环

Peter Steinberger 提出"别再给 Agent 写提示词，去设计提示 Agent 的循环"，把关注点从单次输出转向"发现-规划-执行-验证"的持续循环。

2026.07 — Graph Engineering：多节点组织成图

Steinberger 一句"还在聊 loops 还是已经 shift to graphs 了？“引发热议；Hamel Husain 发文"Loop Engineering Is Dead. Enter Graph Engineering”。核心是把多个 Agent、工具、人组织为可执行有向状态图，强调确定性、可观测、可恢复。

2026.07 — Agent Skills GA + JiuwenSwarm 鸿蒙 PC 版

微软正式发布 Agent Skills for .NET；openJiuwen 推出 JiuwenSwarm 鸿蒙 PC 统一工作台，并定义 HITS（Human in the Swarm）人机协同范式。

关键概念速查

几个容易混淆的概念

SDD 死了吗？

没有。SDD 在被"做薄"，而不是被抛弃。OpenAI 的 Harness 实验中，早期进展缓慢的根因就是"环境规范不够明确"；他们把 AGENTS.md 从百科全书压缩到约 100 行索引地图。规范没有消失，只是从厚重的需求文档变成机器可读的轻量约束。

Harness、Agentic、Loop、Graph 是什么关系？

它们不是替代关系，而是分层关系：

• Harness 偏"环境工程"——给单个 AI 搭规则、测试、沙箱、可观测性；
• Agentic 偏"人机关系"——人从写代码变成指挥 AI 团队；
• Loop 解决"单个智能体如何持续工作"；
• Graph 解决"多个智能体、工具、人如何组成可观测、可恢复、可扩展的系统"。

Loop 没有死，它退居成 Graph 里某个节点内部的运行方式。Graph 的确定性来自普通代码 + 现实锚点（测试真过、钱真到账、用户真留），而不是模型互审。

Coordination Engineering 与 Graph Engineering 有什么区别？

两者都关注多智能体协同，但侧重点不同。Coordination Engineering（openJiuwen 提出）更强调团队成军、动态协商、经验沉淀与自演进，工程载体是 Agent Team、Team Skills、Skills Hub 和自演进机制。Graph Engineering 更强调显式控制流、状态管理、节点边界和可观测性，工程载体是有向状态图和持久化执行（如 LangGraph 的检查点、时间旅行调试）。可以把 Coordination Engineering 看作 Graph Engineering 在"组织行为学"方向上的延伸。

扩散：AI 工程概念地图

RAG

对话开场讨论的 RAG 架构本质：把企业知识库、文档先切块、建索引，生成前按需召回相关片段，再让模型基于证据作答。当前最优路径仍是"评测 → 数据治理 → 检索升级 → 必要时 GraphRAG/多 Agent"。

MCP

Anthropic 提出的 Model Context Protocol，目标是统一 AI 与外部工具、数据源的连接方式。类比 USB-C：接口统一了，设备和应用才能互换对接。

Function Calling

大模型输出结构化参数调用外部工具，是 Agent 和 MCP 的基础能力。没有它，AI 只能"说话"，不能"动手"。

Vibe Coding

Karpathy 命名的"氛围编程"：用自然语言描述需求，全盘接受 AI 生成代码。Demo 快、维护难，通常需要 SDD + Harness 来兜底。

LLM Knowledge Base

Karpathy 2026 年提出的"演进式 Markdown 知识库"思路：人写、AI 辅助维护的长期知识资产，绕过传统 RAG 的复杂检索链路。

Evals / LLM-as-Judge

用评测集衡量 AI 系统效果。没有评测，任何范式改进都是玄学。SDD、Harness、Graph 都离不开它。

HOTS / HITS

openJiuwen 在 JiuwenSwarm 中定义：HOTS（Human on the Swarm）是人站团队外指挥；HITS（Human in the Swarm）是人带身份进团队，与 Agent 同流程协作。

AI-Native

从设计之初就把 AI 作为核心参与者，而不是把 AI 塞进已有流程。RAG 改造、AI 编码、智能客服等都在这个范畴。

Better Harness

Qoder 团队开源的 Coding Agent 工作流分析工具。核心差异是"不唯配置，只看实效"：所有 Finding 必须附带可追溯证据、具体影响、最小修复边界和验证方法，严格保留证据边界，不用其他平台数据填补缺失证据。

Graph Engineering 的落地陷阱

Graph 不是银弹。2026 年 7 月这一波讨论里，有几个常见误区需要警惕。

堆节点不等于高级

最大误会是"节点越多越像工程化"。真正关键的不是节点数量，而是生成与验证是否分离。Verifier 节点必须用干净上下文专门挑刺，而不是让作者审自己。

模型互审不是现实锚点

多个同源 AI 会愉快地互相同意。硬确定性只能来自两块：普通代码（格式校验、跑测试、算预算）和现实锚点（测试真过、钱真到账、用户真留）。纯模型互审无现实锚点 = “更有组织的幻觉工厂”。

工作图可以快变，角色图必须慢变

任务怎么拆（工作图）可以高频调整；但谁能动数据库、谁能绕审批（角色图）必须可审计、慢变更。把两者混为一谈会带来安全和合规风险。

成本会指数级上升

Anthropic 的数据显示，多智能体方案 token 消耗可达单智能体的 15 倍，token 用量能解释 80% 的性能方差。Graph 的额外开销只对"高频 + 高价值 + 要治理"的任务划算。

选型红线： 先用最简单方案，几行 LLM API 能搞定的别上框架；框架（LangGraph / Bedrock / ADK 等）会盖住底层提示，反增调试难度。Anthropic 官方建议是：从 Prompt Chaining 开始，逐步升级到 Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer，最后才考虑完整 Agent。

现状：概念很热，落地很朴素

2026 年的真实工程实践，比这些名词朴素得多。大多数团队的主流做法是：

1. 轻量规范：仓库根目录一份精简的 AGENTS.md（100 行以内），只放 AI 容易忽略的信息；
2. AI 编码代理：Claude Code、Codex、Cursor 等 agent 式工具作为默认工作流；
3. 测试/CI 当护栏：自动化测试、linter、CI 门禁兜住 AI 产出；
4. 可选 MCP/Skill：需要接外部系统时，用 MCP 或 Agent Skills 统一工具接口；
5. 渐进上 Graph：单 Loop 跑到第三轮还搞不定，再考虑拆节点、加 Verifier、接现实锚点。

Harness、Agentic、Loop、Graph、Coordination 这些词大厂和开源社区在推，但离成为"微服务""DevOps"那样有共识的标准还差得远。普通团队不必追名词，抓住"轻量规范 + AI 代理 + 测试护栏 + 反馈闭环"这条骨架就够了。