简介：绝大多数开发者上手 Agent 只会调提示词，做出来的 Demo 一上生产就幻觉、失控、越权、死循环。本文用生活化类比，完整拆解四大 Agent 工程范式，严格区分【思想方法论】和【代码框架实现】，补充生产级 Loop 设计 11 大核心要素，串联 ReAct、CoT、Reflexion 等经典范式，讲清楚为什么 Harness 是底座、Loop 是业务闭环，搭配可落地的工程案例，帮你理解企业级可靠 Agent 的设计思路，适合后端转型 AI Agent 工程师、大模型入门学习者阅读。

目录

1. 前言：为什么你的 Agent Demo 永远无法上线生产

2. 基础定义：先分清两个核心概念 ——「思想方法论」VS「框架工程实现」

3. 第一部分：Prompt Engineering 提示词工程 🧠【思想 / 方法论】

3.1 通俗理解：Prompt 就是给员工写的岗位职责说明书

3.2 Prompt 工程能做什么？边界在哪里？

3.3 Prompt 工程的局限：只靠说明书，员工依然干不完复杂长任务

4. 第二部分：Context Engineering 上下文工程 🧠【思想 / 方法论】

4.1 通俗理解：Context 就是员工手上拿到的项目资料、历史聊天记录

4.2 Context 工程核心工作：不是简单堆文本，而是精细化管理 Token

4.3 Context 和 Prompt 最核心区别：固定指令 vs 动态素材

4.4 典型落地场景：RAG 检索增强本质就是 Context 工程

5. 第三部分：Harness Engineering 底座工程 🧠【思想方法论；代表框架：DeepSeek Harness 🛠️】

5.1 通俗理解：Harness = 安全隔离的现代化办公室

5.2 Harness 四大核心能力拆解：子代理隔离、Skills 渐进加载、沙箱运行、权限管控

① 子代理隔离 SubAgent

② Skills 渐进式加载（标志性优化点）

③ 文件系统沙盒

④ 权限管控

5.3 Harness 的定位：整个 Agent 体系不可缺少的工程底座

6. 第四部分：Loop Engineering 循环工程 🧠【思想方法论；底层范式：ReAct、Reflexion 🧠】

6.1 通俗理解：Loop = 完整项目闭环：定目标→干活→自查→修正→收尾

6.2 经典底层范式：ReAct（思考 + 行动交替），Loop 工程的理论原型

6.3 Loop 标准执行流程：发现目标→执行目标→检查修正→异常抛出→任务结束

6.4 Loop 和 ReAct 的区别：学术范式 vs 工业化可落地闭环

6.5 落地实操：设计生产级 Agent Loop 的 11 大核心要素 🧠【Loop Engineering 落地清单】

Loop 设计要素总表

逐条通俗解读（沿用外包公司类比，保持全书例子统一）

1. 目标 Objective：Loop 要优化 / 完成什么？

2. 触发 Trigger：什么时候运行 Loop？

3. 发现 Discover：怎么找到要干的活？

4. 工作空间 Workspace：Agent 在哪里安全操作？

5. 上下文 Context：有哪些持久化知识？

6. 委托 Delegation：哪个 Agent 做什么？

7. 验证 Verification：怎么判断做对了？

8. 状态 State：什么信息跨会话存活？

9. 预算 Budget：何时停止？

10. 升级 Escalation：什么时候通知人类？

11. 退出 Exit：怎么知道完成了？

小结：11 要素和原生 ReAct 的本质差距

7. 横向串联：四大工程范式完整依赖链路

7.1 层级依赖：Prompt → Context → Harness → Loop

7.2 生活化完整类比：开一家外包公司，对应整套 Agent 架构

8. 延伸拓展：Graph Engineering 图工程 🧠【思想方法论；代表框架：LangGraph 🛠️】

8.1 Loop 管好单个员工反复自查，Graph 管好多个员工分工协作

8.2 什么时候需要引入 Graph？

9. 避坑指南：90% 开发者做 Agent 踩过的认知误区

误区 1：Prompt 写得足够好，就能做出生产级 Agent

误区 2：ReAct = Agent Loop，直接复制论文就能上线

误区 3：Harness 只是代码沙盒，无关紧要

误区 4：Loop 和 LangGraph 互相替代，二选一使用

10. 极简伪代码实战演示：四层范式如何协同工作

11. 总结：生产级可靠 Agent 的设计标准回顾

---

1. 前言：为什么你的 Agent Demo 永远无法上线生产

最近两年，AI Agent 几乎成为所有大模型开发者的必学方向。很多同学入门的路径高度相似： 打开 LangChain 文档，复制一段 ReAct 示例，写几句提示词，调用 LLM，封装一个工具，跑通一个简单问答 Demo。本地测试看起来效果很棒，兴致勃勃准备部署到业务系统，结果上线之后各种灾难接踵而至：

1. 模型随意调用高危文件操作 API，存在删库、篡改业务数据的安全风险；
2. 任务稍微复杂，Agent 无限循环调用工具，Token 疯狂消耗，服务卡死；
3. 上下文越长，模型越容易遗忘前置目标，出现严重幻觉，编造不存在的数据；
4. 多个子 Agent 互相干扰，上下文混在一起，A 子代理拿到 B 代理的私有业务数据；
5. 没有校验机制，工具返回错误结果之后，Agent 直接采信，输出错误业务结论。

出现以上问题，本质原因只有一个：绝大多数开发者只掌握了Prompt Engineering，最多了解 ReAct 这个学术范式，完全不理解一套生产级 Agent 由四层完整工程体系构成：Prompt 工程、Context 工程、Harness 底座工程、Loop 循环工程。

很多资料混杂了「学术思想范式」和「代码开发框架」，新手越看越混乱：ReAct 到底是框架还是思路？DeepSeek Harness 和 LangChain 是什么关系？Loop Engineering 能不能用 LangGraph 实现？

本文核心目标： 用普通人能听懂的生活化例子，完整拆解四大核心工程范式，全程严格标注哪些是通用思想方法论（不受框架限制，可以手写实现），哪些是具体落地框架，打通从简单聊天 Demo，到企业可运维、安全可控、可校验的可靠 Agent 完整知识链路。

前置约定（全文统一区分标准）

🧠 思想 / 方法论：一套设计思路、执行范式、工程准则，和编程语言、开源框架无关，开发者脱离第三方库，纯手写代码也能实现这套逻辑。典型代表：Prompt Engineering、ReAct 范式、Loop Engineering

🛠️ 框架 / 工程组件：现成可运行的代码库、SDK、运行时底座，是思想方法论的工业化落地产物。典型代表：DeepSeek Harness、LangGraph、LangChain

2. 基础定义：先分清两个核心概念 ——「思想方法论」VS「框架工程实现」

在正式讲解四大工程之前，我们先把两个概念讲透，避免后续混淆。

我们拿传统软件开发举例子： 面向对象编程（OOP）是思想方法论，不管你用 Java、Python、Go 都可以实现面向对象； 而 Spring 框架是工程框架，是面向对象思想在 Java 生态下的成熟封装，帮你省去大量重复造轮子的工作。

映射到 AI Agent 领域： ReAct 是思想方法论，它定义了「思考 - 行动 - 观测」交替执行的智能体运行范式，你不用 LangChain、不用任何框架，手写 Python 代码就能实现基础 ReAct 循环； LangChain、DeepSeek Harness 是工程框架，它把 ReAct、工具注册、上下文管理这些通用能力封装好了，降低开发成本。

简单一句话总结：思想回答 “我们应该怎么做”，框架提供 “现成工具帮我们落地做”。 记住这个区分标准，后面所有概念我们都会打上标签，彻底告别概念混淆。

3. 第一部分：Prompt Engineering 提示词工程 🧠【思想 / 方法论】

3.1 通俗理解：Prompt 就是给员工写的岗位职责说明书

假设你是一家外包公司老板，新入职一名员工（对应大模型 LLM）。这名员工基础知识储备很足，但是他不知道你希望他做什么、输出什么格式、遵守哪些规则。

Prompt，就是你写给这名新员工的《岗位职责说明书》。 说明书里面可以写清楚：

1. 你扮演什么角色（高级电商售后分析师）
2. 你的工作目标（分析客户投诉，输出处理方案）
3. 必须遵守的规则（禁止编造订单数据）
4. 输出格式（固定 JSON 格式，包含投诉原因、处理建议）

映射到大模型调用场景： Prompt Engineering（提示词工程），就是设计这套说明书的整套方法论，通过自然语言约束大模型的角色、行为、输出规范、推理方式，引导模型按照我们预期完成单次任务。

3.2 Prompt 工程能做什么？边界在哪里？

Prompt 工程常见能力：

✅ 设定角色身份：你是资深 Python 工程师、专业法务顾问

✅ 约束输出格式：Markdown 表格、标准 JSON、固定段落模板

✅ 定义推理范式：引导模型使用 CoT 思维链分步思考

✅ 约束行为红线：禁止编造数据、禁止执行高危操作

但是，Prompt 工程有非常明确的边界：它管控的是「单次 LLM 调用」的指令模板，它无法管理多轮循环、无法提供工具调用环境、无法保障运行安全。

继续沿用员工例子： 再好的岗位职责说明书（Prompt），只能规范员工每一次汇报该怎么写；说明书本身不能给员工配电脑、不能给员工分配项目资料、不能监督员工做完自查、不能防止员工越权查看其他客户资料。这些能力，需要后面三层工程来补齐。

3.3 Prompt 工程的局限：只靠说明书，员工依然干不完复杂长任务

很多新手存在经典误区：只要提示词写得足够完美，大模型就能搞定一切业务。 我们举一个真实业务场景：让 Agent 帮我们查询数据库订单，统计近 7 天退款金额，生成报表。 只依靠 Prompt 会遇到哪些问题？

1. Prompt 只能告诉模型 “你要查订单统计退款”，但是模型没有调用数据库的工具入口；
2. 如果第一次查询 SQL 写错，Prompt 没有定义重试、自查逻辑，模型直接输出错误报表；
3. 没有权限管控，模型可能编写 DELETE 语句删除业务数据；
4. 任务多轮执行之后，对话上下文膨胀，模型丢失原始目标。

这些痛点，全部超出 Prompt 工程的解决范围。Prompt 只是整套 Agent 架构最上层的指令约束，是起点，而不是全部。

配套延伸概念：CoT 思维链 🧠【思想范式】 CoT（Chain-of-Thought，思维链）属于 Prompt 工程下的经典子范式，核心是引导模型分步输出推理过程，提升复杂推理能力。但是 CoT 只有思考，没有行动，无法调用外部工具，这也是为什么后面诞生了 ReAct。

4. 第二部分：Context Engineering 上下文工程 🧠【思想 / 方法论】

4.1 通俗理解：Context 就是员工手上拿到的项目资料、历史聊天记录

还是外包公司的例子： 岗位职责说明书（Prompt）写好了，员工上岗干活，还需要配套资料：客户历史沟通记录、项目需求文档、参考代码、历史交付成果。这些给到员工、用于完成本次任务的动态素材，就是 Context（上下文）。

Context Engineering（上下文工程），就是一套管理这些资料的方法论：哪些资料给员工看？哪些资料不需要？资料太多如何精简？资料优先级如何划分？什么时候加载资料、什么时候清理过期历史？

4.2 Context 工程核心工作：不是简单堆文本，而是精细化管理 Token

很多新手误以为 Context 就是把所有聊天记录、文档全部拼接发给大模型，这是完全错误的。 上下文工程核心工作包含：

1. 上下文窗口裁剪：超长对话自动丢弃老旧无效信息，防止超出模型上下文上限；
2. 信息优先级排序：核心业务目标置顶，次要参考资料后置；
3. RAG 检索择优：海量文档中，只检索和当前问题相关的片段，减少 Token 消耗；
4. 状态持久化：多轮任务中间结果保存，支持任务中断后恢复；
5. 动态增删上下文：执行不同步骤，动态注入、移除对应素材。

这里补充一个关键常识：大模型输入长度存在上限（上下文窗口），每一段文字都会消耗 Token，Token 直接对应调用成本。不加管控的堆砌上下文，会带来成本暴涨、模型注意力分散、幻觉增多三大问题。

4.3 Context 和 Prompt 最核心区别：固定指令 vs 动态素材

这里做一个清晰对比，避免两者混淆：

• Prompt：固定不变的指令模板，定义角色、规则、输出要求，一次编写，多轮复用；
• Context：每一轮都会变化的动态素材，对话历史、检索文档、工具返回结果、中间计算数据，每一轮调用 LLM 都可能改变。

举一个客服机器人例子： Prompt 固定内容：你是电商售后客服，礼貌回复客户，输出 JSON 格式。（全程不变） Context 动态内容：客户第一轮：我的订单什么时候发货；客户第二轮：我要申请退款。（每一轮不断新增变化）

4.4 典型落地场景：RAG 检索增强本质就是 Context 工程

大家耳熟能详的 RAG 检索增强生成，底层核心就是 Context 工程。 当我们拥有上万份企业文档，不可能一次性全部塞入大模型上下文。Context 工程负责：接收用户问题 → 检索相关文档片段 → 把片段作为上下文素材注入 Prompt，再调用 LLM。 RAG 解决的不是 “怎么写提示词”，而是 “怎么挑选合适资料给到模型”，属于典型 Context 工程落地。

现阶段我们拥有两层能力了：我们有说明书 Prompt，有项目资料 Context。但是员工依然没有办公电脑、没有权限、没有自查闭环，还无法独立完成复杂项目，接下来就需要 Harness 底座。

5. 第三部分：Harness Engineering 底座工程 🧠【思想方法论；代表框架：DeepSeek Harness 🛠️】

5.1 通俗理解：Harness = 安全隔离的现代化办公室

继续外包公司类比： 我们写好了岗位职责说明书（Prompt），准备好了项目资料（Context），但是员工无处办公，没有电脑，不能访问公司数据库，不能读写文件，多个员工办公资料混在一起互相泄密。 Harness，就是我们搭建的现代化、安全隔离办公园区。 园区提供：独立办公室（子代理隔离）、按需领用设备（Skills 渐进加载）、带防护的电脑沙盒（文件系统沙盒）、门禁权限管控（工具权限隔离）。

原文一句话核心结论：Loop 只是你完成一件事的入口，Harness 是完成这件事的工程底座。这句话完全准确，Loop 负责业务执行闭环，但是 Loop 所有动作，都必须运行在 Harness 提供的安全运行环境之上。

5.2 Harness 四大核心能力拆解：子代理隔离、Skills 渐进加载、沙箱运行、权限管控

我们结合 DeepSeek Harness 原生设计，拆解四大核心能力：

① 子代理隔离 SubAgent

大型复杂任务，我们会拆分多个子代理（SubAgent）：A 子代理负责查数据，B 子代理负责生成报表，C 子代理负责发送邮件。 如果不做隔离，所有子代理共用一套上下文、一套工具权限，会出现数据污染、越权访问问题。 Harness 为每一个 SubAgent 分配独立上下文窗口、独立工具权限、独立运行沙盒，子代理之间默认隔离，受控通信。 类比：不同项目员工分配独立办公室，不能随意翻看其他项目保密资料。

② Skills 渐进式加载（标志性优化点）

Skills 就是 Agent 可以调用的工具：SQL 查询、代码执行、文件读写、邮件发送。 新手常见实现方式：启动 Agent 的时候，把所有几十上百个工具的完整描述全部塞入上下文，一次性注入 LLM。带来的问题：巨量 Token 浪费，大量工具本次任务根本不会用到。

渐进式加载策略： Agent 初始化时，只注入工具名称极简列表，不传入完整工具描述；只有当 Agent 本轮决定调用某个工具时，Harness 才动态加载这个工具的完整定义、参数规范，传入上下文。 官方数据：该优化最高可以节省 97.5% 的 Token 开销，是 Harness 工程非常关键的性能优化手段。 类比：公司仓库有上百种工具，员工上岗只知道工具清单；需要使用电钻的时候，才去仓库领取电钻完整使用说明书，而不是上岗一次性把所有设备手册全部给到员工。

③ 文件系统沙盒

Agent 具备读写本地文件、执行代码的能力，如果不隔离，Agent 有可能读取服务器敏感配置文件、删除业务文件。 沙盒提供隔离文件运行环境，Agent 只能访问分配的隔离目录，无法触碰宿主机核心文件，操作日志完整留存，出现问题可以审计溯源。

④ 权限管控

细粒度管控每个子代理可以调用哪些工具：数据查询子代理只允许 SELECT 查询 SQL，禁止 DELETE/UPDATE 写入操作；邮件子代理只允许发送指定收件人，禁止对外群发。

5.3 Harness 的定位：整个 Agent 体系不可缺少的工程底座

Harness 向上承接 Context、Prompt，为 Agent 提供可执行工具、安全运行环境；向下支撑 Loop 循环执行。 没有 Harness，Loop 里面所有工具调用都是空中楼阁，存在极大安全隐患，也无法实现多子代理隔离、Token 优化。

框架区分标注： Harness Engineering 是一套通用底座设计思想 🧠；DeepSeek Harness 是这套思想工业化实现的开源框架 🛠️。 我们完全可以不用 DeepSeek Harness，基于 LangChain 自研一套隔离运行时，实现 Harness 全部能力。

6. 第四部分：Loop Engineering 循环工程 🧠【思想方法论；底层范式：ReAct、Reflexion 🧠】

6.1 通俗理解：Loop = 完整项目闭环：定目标→干活→自查→修正→收尾

外包公司场景继续延伸： 我们拥有员工说明书（Prompt）、项目资料（Context）、安全办公园区（Harness），员工可以干活了。 但是复杂任务很难一次交付合格成果：第一次交付的报表存在数据错误，我们需要一套流程：员工接收目标 → 动手执行 → 自查成果是否达标 → 发现错误修正重试 → 多次校验通过之后交付，严重异常直接终止任务抛出报错。 这套持续迭代、自检、重试、终止的闭环设计思路，就是 Loop Engineering（循环工程）。

6.2 经典底层范式：ReAct（思考 + 行动交替），Loop 工程的理论原型

ReAct（Reasoning + Acting，思考与行动）2022 年经典论文范式 🧠【思想范式】，是绝大多数 Agent Loop 底层理论基础。 标准 ReAct 三轮交替循环：

1. Thought 思考：LLM 基于现有信息，推理下一步需要做什么动作；
2. Action 行动：调用工具执行操作（查询数据库、运行代码）；
3. Observation 观测：接收工具返回的真实结果，作为客观证据； 观测结果重新放回上下文，进入下一轮 Thought，直到任务完成输出答案。

ReAct 解决了 CoT 纯空想的缺陷：模型不再只停留在文字推理，可以和真实外部环境交互，用工具获取客观证据，减少幻觉。

6.3 Loop 标准执行流程：发现目标→执行目标→检查修正→异常抛出→任务结束

Loop 标准流程：发现目标 -> 执行目标 -> 检查修正 -> 抛出 -> 结束，我们做严谨扩写，消除歧义：

1. 发现目标：解析顶层业务目标，拆解子任务，确认终止验收标准；
2. 执行目标：调用 LLM 做决策，通过 Harness 提供的工具执行动作（ReAct Thought+Action）；
3. 检查修正：基于观测证据校验结果是否满足验收标准；合格则结束任务；不合格进入重试修正逻辑；
4. 异常抛出：重试达到上限、权限不足、业务规则冲突等不可修复问题，抛出异常，终止任务，留存审计日志；
5. 结束：校验通过，整理最终结果输出。

补充增强范式 Reflexion 🧠【思想范式】：Reflexion 在 ReAct 基础上增加了自我反思环节，每一轮执行完成之后，Agent 主动复盘上一轮错误，优化后续决策，适合代码开发、复杂数学计算等高难度场景，属于 Loop 工程可以选用的增强策略。

6.4 Loop 和 ReAct 的区别：学术范式 vs 工业化可落地闭环

很多新手混淆两者，这里明确区分： ✅ ReAct：论文提出的基础学术范式，只定义 Thought/Action/Observation 交替逻辑，没有定义重试上限、异常捕获、终止规则、日志审计、防死循环策略；适合论文实验、简单 Demo。 ✅ Agent Loop / Loop Engineering：ReAct 范式的工业化扩展闭环，在 ReAct 基础上增加重试策略、终止条件、异常处理、结果校验、状态持久化，适配生产环境稳定性要求。

一句话概括：ReAct 是理论原型，Loop Engineering 是可以上线商用的完整工程方案。

6.5 落地实操：设计生产级 Agent Loop 的 11 大核心要素 🧠【Loop Engineering 落地清单】

前面我们讲清楚了 Loop 工程的定义、和 ReAct 的区别，但是从理论走向落地，最大的难点是：我们到底该从哪些维度去设计一个可靠的循环？ 很多开发者写 Loop 只实现了 “思考→调用工具→拿到结果”，缺少边界控制、校验、异常升级机制，上线之后极易出现死循环、任务失控、出错无人兜底等线上故障。

行业内一套成熟的落地规范，把设计 Loop 拆解为 11 个必须定义清楚的核心要素，每一个要素都对应一个设计问题，同时附带工程示例，下面我们先用总表汇总，再逐条通俗拆解。

Loop 设计要素总表

表格

要素	核心设计问题	业务示例
目标（Objective）	Loop 要优化 / 完成什么？	"保持 CI 流水线绿色（持续构建不报错）"
触发（Trigger）	什么时候运行这个 Loop？	每 10 分钟轮询 / CI 构建失败事件触发
发现（Discover）	怎么找到需要处理的任务？	读取 CI 运行日志、扫描 GitHub Issues
工作空间（Workspace）	Agent 在哪里安全执行操作？	Git Worktree 隔离目录、文件沙盒
上下文（Context）	任务有哪些持久化参考知识？	SKILL.md 工具说明文档、CLAUDE.md 约束规范
委托（Delegation）	划分职责：哪个 Agent 负责做什么？	maker-agent（执行修改） vs checker-agent（校验结果）
验证（Verification）	如何判断本次任务做对了？	自动化单元测试全部通过
状态（State）	哪些数据需要跨轮次、跨会话持久保存？	任务进度文件、可视化任务看板
预算（Budget）	资源耗尽时何时强制停止循环？	最大循环轮数、Token 消耗上限、任务超时时间
升级（Escalation）	什么场景需要转交人类介入处理？	三次重试全部失败 → 创建 Issue 并 @负责人
退出（Exit）	如何判定整个任务正式完成，可以结束 Loop？	独立评估器模型判定验收标准达成

💡 重要关联说明： 工作空间 Workspace 本质属于 Harness 底座能力；Context 对应前文 Context Engineering； 验证、预算、升级、退出规则，是 Loop Engineering 最核心的工程边界设计，也是原生 ReAct 论文完全没有覆盖的工业化内容。

逐条通俗解读（沿用外包公司类比，保持全书例子统一）

1. 目标 Objective：Loop 要优化 / 完成什么？

设计问题：Loop 要优化什么？ 示例：保持 CI 绿色

通俗理解：给整套循环定清晰、可验收的最终目标，不能是模糊需求。 ❌ 坏目标：帮我维护代码 ✅ 好目标：自动修复 CI 流水线报错，保证每次提交后 CI 流水线能够成功跑完（保持 CI 绿色）

目标必须可量化、可验证，后面的【验证】【退出】环节都依赖这个目标定义。 对应公司类比：项目立项，明确这个项目最终交付成果是什么。

2. 触发 Trigger：什么时候运行 Loop？

设计问题：什么时候运行？ 示例：每 10 分钟 / CI 失败事件

通俗理解：定义循环的启动时机，分为两种模式

1. 定时轮询：每隔固定时间自动启动 Loop；
2. 事件驱动：监测到特定事件发生才触发 Loop（推荐生产使用，节省资源）

类比：运维团队，可以定时巡检服务器，也可以收到告警消息之后再启动故障处理流程。

3. 发现 Discover：怎么找到要干的活？

设计问题：怎么找到要干的活？ 示例：读取 CI 日志、GitHub Issues

通俗理解：Loop 启动之后，第一步要自动抓取待处理任务清单。 Agent 不能被动等待人类下发指令，需要具备主动发现待办的能力：读取日志、扫描工单、检索缺陷列表。

类比：项目助理上班之后，先查阅邮件、工单系统，整理今天需要处理的工作清单。

4. 工作空间 Workspace：Agent 在哪里安全操作？

设计问题：Agent 在哪里安全操作？ 示例：Git Worktree 隔离

通俗理解：Agent 执行文件修改、代码运行的隔离环境，归属 Harness 底座能力。 绝不允许 Agent 直接操作主工作目录，必须分配独立隔离工作区，操作可回溯、可销毁，防止破坏线上原始代码、敏感文件。 常见实现：文件沙盒、Git Worktree、独立容器。

类比：员工修改正式合同前，先复制一份文档到独立草稿文件夹，草稿改错不会影响原始正式文件。

5. 上下文 Context：有哪些持久化知识？

设计问题：有哪些持久化知识？ 示例：SKILL.md、CLAUDE.md

通俗理解：任务全程可以复用的静态参考文档、约束规范，属于 Context Engineering 范畴。 比如工具使用文档、编码规范、安全红线文档，在整个 Loop 生命周期持久可用，按需加载（搭配 Harness 的 Skills 渐进加载优化 Token）。

类比：员工全程可以查阅公司制度手册、技术规范文档。

6. 委托 Delegation：哪个 Agent 做什么？

设计问题：哪个 Agent 做什么？ 示例：maker-agent vs checker-agent

通俗理解：多子 Agent 场景下做职责拆分，分工隔离，避免单一 Agent 既当运动员又当裁判。 经典分工：maker 负责执行改动、编写代码；checker 负责校验 maker 产出是否符合规范。 职责隔离可以大幅降低幻觉带来的风险，也是 SubAgent 隔离能力的典型使用场景。

类比：开发写代码（maker），测试负责验收（checker），权责分离。

7. 验证 Verification：怎么判断做对了？

设计问题：怎么判断做对了？ 示例：测试通过

通俗理解：每一轮循环动作完成后，必须有校验手段，判断本轮产出是否合格。 校验方式不限于 LLM 自评，优先使用客观自动化手段：单元测试、接口断言、格式校验，减少模型幻觉带来的误判。

重点坑：不要让执行任务的 Agent 自己验证自己的成果，最好交给独立 checker-agent 做校验。

类比：写完功能代码，运行自动化测试，确认功能符合需求。

8. 状态 State：什么信息跨会话存活？

设计问题：什么信息跨会话存活？ 示例：进度文件、看板

通俗理解：持久化任务中间进度，支持任务中断、重启、断点续跑。 如果服务重启、LLM 调用超时，不能丢失已经完成的工作进度。状态数据可以落地为文件、数据库、任务看板。

类比：项目管理看板，记录每个需求开发到哪一步，换项目经理接手也能继续推进。

9. 预算 Budget：何时停止？

设计问题：何时停止？ 示例：最大轮数、Token 上限、时间限制

通俗理解：防失控的熔断保护，Loop 最重要的安全边界之一。 必须设置资源上限：最多循环多少次、总 Token 消耗上限、最长运行时间。一旦触碰预算红线，强制终止循环，杜绝无限死循环疯狂消耗算力与资金。

类比：给项目设置预算和工期，超预算、超工期强制暂停项目，评估后再决定是否继续。

10. 升级 Escalation：什么时候通知人类？

设计问题：什么时候通知人类？ 示例：三次重试失败 → 创建 Issue 并 @负责人

通俗理解：定义自动化无法解决时的兜底策略。 当多次重试失败、权限不足、业务冲突，Agent 无法自主处理，不能静默卡死，要主动升级告警，把任务转交人工处理，留存完整审计日志。

类比：一线客服处理不了客户投诉，自动升级到主管介入跟进。

11. 退出 Exit：怎么知道完成了？

设计问题：怎么知道完成了？ 示例：独立评估器模型判断

通俗理解：判定整个大任务全部验收通过，正常结束 Loop，和上面 Budget 熔断退出区分：

• Exit：任务圆满达标，正常结束；
• Budget：资源耗尽，异常强制终止。 推荐使用独立评估器（单独的 Checker Agent / 自动化用例）判断是否达成最初【Objective】目标，不允许执行方自行判定结束。

小结：11 要素和原生 ReAct 的本质差距

原生 ReAct 范式，只覆盖了循环里「Thought → Action → Observation」的执行环节； 而这一套 11 要素规范，补齐了：启动时机、任务发现、安全隔离、分工校验、状态持久、资源熔断、人工兜底、正常退出全套工业化边界规则。 拥有这套完整设计清单，才算是真正落地了 Loop Engineering，而不是写一个玩具 Demo。

7. 横向串联：四大工程范式完整依赖链路

7.1 层级依赖：Prompt → Context → Harness → Loop

四层严格上下游依赖，顺序不能颠倒：

1. Prompt Engineering：定义单次调用的角色、规则、输出模板；
2. Context Engineering：管理动态任务素材、对话历史、Token 开销；
3. Harness Engineering：提供安全沙箱、工具注册、权限隔离、SubAgent 运行底座；
4. Loop Engineering：在底座之上，搭建迭代、校验、重试、终止的业务执行闭环。

没有上层，下层无法运行；没有下层，上层无法完成复杂任务。 只做 Prompt+Context，最多实现问答机器人；叠加 Harness 之后，Agent 拥有安全调用工具的能力；最后叠加 Loop，Agent 具备自主完成复杂长任务的能力。

7.2 生活化完整类比：开一家外包公司，对应整套 Agent 架构

我们把整套体系映射成完整公司，方便记忆：

表格

Agent 工程范式	对应公司角色 / 组件	核心职责
Prompt Engineering	员工岗位职责说明书	规定员工角色、工作规范、交付格式
Context Engineering	项目资料、客户沟通记录、需求文档	员工干活需要用到的动态参考素材
Harness Engineering	办公园区、独立办公室、门禁、电脑设备、仓库工具	提供安全隔离的办公环境、设备权限管控
Loop Engineering	项目管理流程：立项→开发→自测→修改→验收→异常终止	整套项目交付闭环，管控迭代、自查、收尾
LLM 大模型	员工本人	负责思考、决策，执行分配的工作

8. 延伸拓展：Graph Engineering 图工程 🧠【思想方法论；代表框架：LangGraph 🛠️】

在四大范式之外，还有上层 Graph 工程，也就是原理图里 GRAPH 模块，这里补充讲解，形成完整知识体系。

8.1 Loop 管好单个员工反复自查，Graph 管好多个员工分工协作

Loop 管控的是单个 Agent 内部反复迭代、自检的闭环； 当业务复杂度继续提升，出现下面场景，单一 Loop 无法满足需求：

1. 流程存在分支判断：订单正常走自动处理，异常订单流转人工审批；
2. 多子 Agent 并行工作：数据分析 Agent、文案生成 Agent 同时执行，完成之后汇总结果；
3. 人工介入节点：关键步骤暂停执行，等待人类审批确认之后继续运行；
4. 多任务汇合：多条并行子流程全部完成之后，统一进入下一步。

Graph Engineering（图工程），就是使用有向工作流编排多个独立 Agent Loop、人工节点、分支路由的工程思想。

8.2 什么时候需要引入 Graph？

简单任务：单个 Agent，线性循环执行 → 只用 Harness + Loop 足够； 复杂企业业务：多分支、人工卡点、多子 Agent 协同、流程可追溯 → 引入 Graph 做顶层编排。

框架区分标注：Graph Engineering 是编排思想 🧠；LangGraph 是这套思想最主流的落地开发框架 🛠️；当然也可以自研工作流引擎实现 Graph 能力。

补充经典搭配方案：LangGraph 做顶层 Graph 编排，每个节点内部，运行一套基于 DeepSeek Harness 搭建的 Agent Loop。

9. 避坑指南：90% 开发者做 Agent 踩过的认知误区

误区 1：Prompt 写得足够好，就能做出生产级 Agent

❌ 错误：Prompt 只能约束单次 LLM 调用行为，无法解决安全隔离、循环重试、上下文膨胀、工具权限管控等工程问题。再好的提示词，也救不了缺少 Harness 和 Loop 设计的 Agent。

✅ 正确：Prompt 是基础配置，整套四层工程体系才是生产 Agent 核心。

误区 2：ReAct = Agent Loop，直接复制论文就能上线

❌ 错误：原生 ReAct 缺少重试上限、防死循环、结果校验机制，直接上线极易出现无限循环疯狂调用工具。

✅ 正确：ReAct 作为底层推理范式，必须经过 Loop Engineering 工业化改造，补充各类容错、终止规则之后，才能业务落地。

误区 3：Harness 只是代码沙盒，无关紧要

❌ 错误：沙盒只是 Harness 其中一个安全组件，Harness 还包含 SubAgent 隔离、Skills 渐进加载、全链路权限管控、状态隔离整套运行时能力，决定整套 Agent 是否安全、低成本运行。

✅ 正确：Harness 是底座，底座设计缺陷，上层 Loop 再完美也存在安全与稳定性隐患。

误区 4：Loop 和 LangGraph 互相替代，二选一使用

❌ 错误：两者不在同一个层级，不存在替代关系。

✅ 正确：LangGraph（Graph）负责多节点流程编排；每个节点内部，可以独立运行一套 Agent Loop。二者经常搭配使用。

10. 极简伪代码实战演示：四层范式如何协同工作

伪代码仅用于理解四层如何配合，可直接转为 Python 可运行代码

# ========== 1. Prompt Engineering 固定指令模板【Prompt层】
SYSTEM_PROMPT = """你是订单数据分析Agent，禁止编造数据，输出严格JSON格式。
可用工具：query_order_sql、export_report
"""

# ========== 2. Context Engineering 动态上下文管理【Context层】
context = ContextManager()
context.append("业务目标：统计近7天退款订单总额")
context.load_rag_docs(["售后报表规范文档"])

# ========== 3. Harness Engineering 初始化安全运行底座【Harness底座】
harness = HarnessRuntime()
# 注册工具，开启渐进式加载
harness.register_skill("query_order_sql", permission=["SELECT"], lazy_load=True)
harness.register_skill("export_report", permission=["write_sandbox"], lazy_load=True)
# 创建隔离子代理
sub_agent = harness.create_subagent(independent_context=True)

# ========== 4. Loop Engineering 搭建执行闭环【Loop循环层】
agent_loop = AgentLoop(
    harness=harness,
    max_retry=3, # 重试上限，防止死循环
    validate_func=check_report_valid # 结果校验函数
)
# 启动循环执行任务
final_result = agent_loop.run(
    prompt=SYSTEM_PROMPT,
    context=context
)
print(final_result)

我们从代码可以清晰看到依赖关系：Loop 依赖 Harness，Harness 承载工具隔离，Prompt 和 Context 作为入参传入循环。

11. 总结：生产级可靠 Agent 的设计标准回顾

我们回顾整套体系，完整定义可靠 Agent 建设标准：

1. Prompt 工程：约束模型角色、输出规范，让模型听懂指令；
2. Context 工程：精细化管理动态素材，控制上下文 Token 开销；
3. Harness 底座工程：提供安全隔离运行环境、工具权限、子代理隔离，让 Agent 具备安全干活的基础；
4. Loop 循环工程：基于 ReAct/Reflexion 范式搭建自检重试闭环，搭配 11 大设计要素，让 Agent 可以自主完成目标，结果可校验；
5. Graph 图工程（复杂业务可选）：编排多 Agent、分支、人工审批，实现全流程显式可控。

同时再次巩固「思想 vs 框架」区分： 🧠 思想方法论：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering、Graph Engineering、ReAct、CoT、Reflexion（无绑定框架，可自研实现） 🛠️ 落地框架：DeepSeek Harness、LangGraph、LangChain（思想的工业化封装，提升开发效率）

对于想要转型 AI Agent 工程师的开发者来说，不要沉迷调提示词，重点理解整套工程分层思想。企业招聘生产级 Agent 开发岗位，考察核心不再是会不会写 Prompt，而是能不能设计安全、可校验、可运维的 Harness 底座与 Loop 闭环。