关系？哪一个是真正的下一代，哪一个是营销包装？

再看一条主线。瓶颈在往外移

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

• 2023 年大家卷提示词，因为模型第一次能听懂复杂指令；• 2024 年发现提示词写得再好，模型看不到关键上下文也白搭。于是 Context Engineering 兴起；• 2025 年又发现上下文给对了环境约束不对照样翻车，于是 Harness Engineering 成为热点；• 2026 年中单智能体循环再精致也扛不住复杂任务，于是多智能体编排和图结构成为新战场。怎么说呢，

使用者痛点：很多团队在实际项目中感到“到底该先搞 Prompt 还是先搞 Context？”、“投入大量 Prompt 仍然出错”，这些困惑正是瓶颈转移的直接表现。

从时间线来看。从 RAG 到 Graph Engineering

— RAG：给模型接外脑

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

— ChatGPT：对话式 AI 爆发

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

— Prompt Engineering + Copilot 普及

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

— MCP：工具接口标准化

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

— Vibe Coding：Karpathy 的“氛围编程”

用自然语言描述需求，全盘接受 AI 生成代码。怎么说呢，门槛极低、Demo 极快。但维护成本极高——“没人知道代码在做什么”。这正是许多团队在实际落地时最头疼的地方。

— Context Engineering：从“怎么写”到“给什么”

Karp­thy 公开支持 Context Engineering 取代 Prompt Engineering。关注点变成代码库上下文、Git 历史、依赖关系、检索文档等 “模型看到的信息环境”。使用者痛点：“我已经把 Prompt 调得很完美，却仍然找不到正确的依赖文件。”

— SDD：规范驱动开发

作为 Vibe Coding 的反面出现：先写 Spec，再让 AI 按规范生成。OpenSpec、Spec Kit、BMAD 等工具相继出现；2025 月 LG CNS 与 Cline 发布公司级 Spec Driven 网站，腾讯 CodeBuddy SPEC 模式也获得工程圈认可。老实说，

— Harness + Agentic Engineering

Mitchell Hashimoto 提出 Harness Engineering。OpenAI 用 “人‑个月零手写代码交付百万行” 引爆；Karpathy 同阶段提出 Agentic Engineering，主张 “% 时间不再直接写代码”。使用者痛点：团队担心没有足够的监控手段来防止 AI “跑偏”。

— Coordination Engineering：openJiuwen 的“协同工程”

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

— Loop Engineering：单智能体自循环

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

— Graph Engineering：多节点组织成图

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

— Agent Skills GA + JiuwenSwarm 鸿蒙 PC 版

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

关键概念速查

几个容易混淆的概念 & 使用者痛点解答

SDD 死了吗？其实，

• No。它在被"做薄",而不是被抛弃。OpenAI 的 Harness 实验中早期进展缓慢的根因就是 "环境规范不够明确"；他们把 AGENTS.md 从百科全书压缩到约 30 行索引地图。规范没有消失，只是从厚重需求文档变成机器可读的轻量约束。
• 至于*实战建议*，保留一份精简的 Spec。配合自动化校验，让 AI 能快速读取关键约束，同时避免维护冗余文档导致的信息噪声。

关系？

• Harness：偏"环境工程"- 给单个 AI 搭规则、测试沙箱和可观测性；适用于想快速上线安全 Guardrails 的团队。怎么说呢，
• Agentic：偏"人机关系"- 人从写代码变成指挥 AI 团队；说起来，适合已有成熟 DevOps 流程。需要将决策权下放给 LLM 的场景。
• Loop："单个智能体如何持续工作";当你只想让一个 Agent 循环完成「发现‑规划‑执行‑验证」时使用。说起来，
• Graph："多个智能体/工具/人如何组成可观测/可恢复程序";说起来，当业务流程涉及跨部门、多工具协同且需审计时才考虑引入。
• 再看*实战方法*，先用 Harness + 简易 Loop → 再根据业务复杂度逐步抽象为 Graph → 在需要跨团队协作时加入 Coordination 层。

Coordination Engineering 与 Graph Engineering 有什么区别？

• They both focus on multi‑agent collaboration,but ir emphasis differs.
• A) Coordination Engineering:强调团队成军、动态协商、经验沉淀与自演进——工程载体是 Agent Team 、Team Skills 、Skills Hub 与自演进机制。更像组织行为学层面的治理。
• B) Graph Engineering:强调显式控制流、状态管理和可观测性——工程载体是 有向状态图 、持久化执行。更偏技术实现层面的确定性保障。
• 选型建议如果你的痛点是「谁可以访问数据库？」、「审批流如何追溯，」优先考虑 Coordination；如果痛点是「任务分支后如何保证结果一致？」则直接评估 Graph 框架。
`

至于扩散，AI 工程概念地图 & 常见痛点映射表格 ...

Graph Engineering 落地陷阱 & 痛点警示

堆节点不等于高级 .

< li> 最大误会是「节点越多越像工程化」。说起来，真正关键不是节点数量。而是 将生成与验证分离 Verifier 节点必须用干净上下文专门挑刺，而不是作者审自己。<\/Li> <\/ul>

模型互审不是现实锚点 .

 - 多个同源 A I 会愉快地互相同意。- 硬确定性只能来自两块：
* 普通代码
* 实际锚 点 （测试真过&钱真到账&使用者真留)
- Pure model audit = 「更有组织幻觉工厂」

---

...

#概念&痛点映射	Description	Solved Pain Point	Status/Adoption
RAG	检索+生成程序。使 LLM 能引用外部证据	解决「LLM 知识陈旧」的问题	大部分公司已落地
MCP	统一 LLM 与外部工具/数据源连接方式	解决「接口碎片化」导致集成成本高	正在标准化
Function Calling	LLM 输出结构化参数调用外部工具	让 LLM 从「说话」转向「动手」	所有主流网站均已实现
Vibe Coding	全盘自然语言描述需求并交付代码	快速原型，但会产生「无人维护」风险	已被 SDD+Harness 抵消