AI Agent 工程化六层架构从 Prompt 到 Production读懂 Loop Engineering / Graph Engineering / Harness Engineering。以及它们为什么不是又一轮 buzzword 炒作。而是构建生产级 AI Agent 的真正基础。你最近大概在 X / Reddit / 技术博客上频繁撞见这几个词Loop Engineering、Graph Engineering、Harness Engineering、评估用例Evals。字面上看像又一轮造词运动。但 Dr. Maryam Miradi 在这支 18 分钟的视频里用一句话把它们拉下神坛They didnt go viral because they are complicated or magical. They are actually very simple building blocks.「它们能走红不是因为复杂或神奇。它们其实是非常简单的基础构件。」她用同一个保险理赔 Agent 系统从头穿到尾。把这六层讲明白了。本文是该视频的图文重构。保留关键洞见补上术语解释和中文语境下的迁移思路。0. 先从一个问题开始假设你已经用 LangGraph 搭了一套保险理赔 Agent 系统。5 个 Agent 协作。从理赔受理到最终赔付流程走完、图跑通了。然后你发现损伤程度明明是轻微系统却批准了 $4,500 赔付。五个 Agent 跑完了。图跑完了。答案还是错的。现在开发者必须手动检查每一条追踪记录。修改逻辑。然后重新跑整个流程。这就是这六个工程层要填补的缺口。1. Prompt Engineering → Context Engineering打地基最基础的起点写 prompt。给模型一个角色「你是一个专业的损伤文档助手」、任务、约束、输出格式。这是Prompt Engineering。定义一次交互应该长什么样。问题也很明显它是一次性的one-shot。你可以加 loop 和迭代。但它本身解决不了复杂问题。而且模型回答需要信息。所以你需要Context Engineering。Context Engineering 的关键动作把所有可用的信息塞进上下文。在保险理赔系统里就是保单policy、客户信息customer、事故细节incident、损伤描述damage。全部结构化地喂给模型。然后模型才能做损伤证据评估、保单决策、风险评估、赔付建议。但这引出一个新问题上下文窗口虽然越来越大模型在约 10% 窗口位置就开始「腐化」context rot。ChromaDB 的研究发现超过这个阈值模型错误率显著上升。Dr. Mirami 在她的进阶 Context Engineering 视频里讲了 7 种应对方法。上下文压缩compaction、Agent 即工具agent as a tool等。但根本局限还在We do not know for sure that the agent is going to do the task reliably.「我们无法确定 Agent 是否一定会可靠地完成任务。」你不知道 Agent 到底会不会可靠完成任务。所以需要下一层。2. Agent Execution Engineering定义「一个 Agent 怎么干活」这一层的关键问题一个 Agent 在所有情况下应该怎么行动以保险理赔受理 Agent 为例。围绕「接收理赔」这单一职责要做的事远比想象的多理赔类型 → 规范化 → 验证 → 声明依赖需求 → 从已验证字段构建证据 → 损伤证据存在性 → 自定义状态长度 → 既往理赔 → 迟报 → 置信度评估 → 受理完成 → 审计事件不是「一个 Agent 做一个任务」。而是确保这个 Agent精确地做业务要求它做的事。执行的引擎是ReAct 模式Reason推理→ Act行动→ Observe观察→ Feedback反馈→ Replan/Retry重规划/重试→ Stop完成时停止。但 Agent Execution Engineering 只定义了「一次尝试」怎么运作。如果那次尝试不够好呢3. Loop Engineering本文重点Loop engineering defines what happens when that attempt is not good enough.「Loop engineering 定义了当那次尝试不够好时该怎么办。」Loop Engineering 的定位当一次尝试不够好时系统应该做什么。评估什么继续什么重试多少次要不要人介入3.1 无 Loop vs 有 Loop无 Loop 的保险系统图理赔受理 → 损伤证据 → 赔付 → 人工审核 → 驳回/自动批准 → 结束每个节点只经过一次。决策在那一刻定型。加上 Loop 之后理赔受理 → 损伤尝试 (×1…20) → 循环评估 → 损伤循环决策 → 图构建器 → 评估 → 路由 → (返回损伤尝试 或 继续前进)关键差异损伤循环决策damage loop decision和路由节点router形成闭环。直到条件满足才往前走。这不仅仅是「加个 while 循环」。Loop Engineering 定义了多层反馈环的层次结构3.2 四层 LoopLoop 1任务执行环Task Action/Observation最基础的一层。每个 Agent 都在做这件事。执行任务、观察到结果。这一直都存在。不新鲜。Loop 2验证反馈环Verification → Feedback → Retry until criteria pass这是关键升级。任务做完后有一个独立的验证步骤评判结果是否达标。不达标就重试直到通过。这是 Critic、Evaluator、Self-healing、Human-in-the-loop 这些设计模式所在的位置。Loop 3事件驱动环Event-driven → Auto-update on new data系统不再「跑一次就停」。当新数据到达时自动重新运行并更新状态。这是一个持续自我更新的系统。Loop 4爬山改进环Hill-climbing → Multi-round pattern improvement最高层。不只是单次任务变好。而是从多轮反馈中提取模式改进未来的每一轮。这是系统在「学习」。3.3 Loop Engineering × 设计模式设计模式告诉你局部用什么反馈机制critic 批评者、evaluator 评估者、self-healing 自愈。Loop Engineering 告诉你反馈如何在整体 Agentic 系统中运作。横跨 Agent 执行、编排、管控、生产系统。无处不在。Dr. Mirami 用 Andrew Ng 的产品开发三层 Loop 做了进一步说明Loop速度做什么类比Agentic Coding Loop分钟级写代码→跑测试→浏览器检查→迭代直到满足 spec开发者在 IDE 里的内环Developer Feedback Loop10 分钟~2 小时Review 产品→给反馈→更新 spec 和优先级→回到 Loop 1团队代码审查 迭代External Feedback Loop小时~天~周使用数据用户反馈→调整产品方向A/B 测试 产品决策3.4 「Loop Engineering will surprise you」Dr. Mirami 开场说「loop engineering will surprise you」。她指的是It is everywhere from prompt engineering to production agent engineering. The shape of it will look different, but it is everywhere — to improve and use feedback as a pattern to make our agentic system better.「它无处不在从 prompt engineering 到 production agent engineering。形态各异但无处不在用反馈作为模式来改进让我们的 Agentic 系统变得更好。」Loop Engineering 不是某个特定技术。而是一种跨越所有层的反馈思维。4. Graph Engineering编排图 vs 知识图Graph Engineering 涉及两类图。用途完全不同4.1 Orchestration Graph编排图这是LangGraph 做的事。定义 Agent 之间的执行流理赔受理 → 损伤评估 → 评估 → 保单 → 风险 → 赔付 → 路由 → …每个节点是一个 Agent 或一个决策点。边是条件跳转。用 supervisor、aggregator、human approval 等模式做协调。但结构本身不保证可靠性。图跑通了不代表结果对了。4.2 Knowledge / Memory Graph知识/记忆图这是GraphRAGMicrosoft做的事分块 → 实体提取 → 社区检测 → 社区总结 → 生成答案Graph Memory 则是跟踪实体关系随时间的变化。例如「我在哪工作」这个事实是可能改变的。4.3 什么时候用 Graph什么时候不用用 Graph 的场景多跳查询、时序推理、需要综合多个信息源、时间敏感信息。不用 Graph 的场景简单单步查询、成本敏感、不需要跨实体推理、entity resolution 质量无法保证时。Bad entity resolution breaks multi-hop trust.「糟糕的实体解析会破坏多跳推理的可信度。」如果实体名称不完全一致比如「Maryam Miradi」vs「Dr. Mirami」多跳推理的可信度就会崩溃。Dr. Mirami 做了五年图分析欺诈检测。她的经验图计算非常昂贵应该用 lazy 策略。不要构建整个图只构建你需要的那部分。Use graph for orchestration always, but for knowledge always selectively.「编排图始终用但知识图要始终有选择地用。」5. Harness Engineering让 Agent 可控Harness Engineering 回答怎么让 Agent 和 Graph 的执行变得可靠、可控、可观测5.1 评估用例是重心Dr. Mirami 为保险理赔 Agent 写了72 个评估用例test_image_mismatch— 图片和理赔类型不匹配test_low_confidence_triggers— 低置信度触发人工审核test_risk_score_for_escalation— 风险评分是否触发升级test_invalid_policy_triggers_escalation— 无效保单触发升级test_excluded_coverage— 排除条款被触发test_payout_above_limit/test_payout_below_limit— 赔付金额越界每一个边界条件都有一条测试。测试即文档测试即护栏。5.2 Harness 的完整结构输入 → 入口验证 → Agent 编排 → 出口验证 → 输出 贯穿始终 ├── 运行时策略重试、超时、限流、熔断 ├── 可观测性日志、指标、仪表盘、告警 ├── 状态管理 ├── 审计追踪 ├── 人工介入点 └── 密钥管理6. Production Agent Engineering全部整合到这一层前面所有层融合为一个可用的业务系统。架构图用户和渠道 ↓ Agent 管控层第六层的所有东西 ↓ 企业工具和指南 ├── 安全 ├── 人工介入 ├── 部署 └── 监控和指标Dr. Mirami 在构建医疗 Agent 时用了同样的思路。5 个插件、LLM-as-a-Judge、13 条生产标准。Nowadays it is not anymore about what you built — because the code is getting faster and faster by Claude Code and Codex. Its more of: do we reach the point that businesses ask us to? Do we deliver on what they want?「如今的焦点不再是你构建了什么。因为代码产出因 Claude Code 和 Codex 越来越快。真正的问题是我们是否达到了业务的要求我们是否交付了他们真正想要的东西」代码产出越来越快。Claude Code、Codex 让写代码不再是瓶颈。真正的问题是系统是否达到了业务要求7. 对你的项目三个可立刻落地的点第一显式化反馈环。你的任何一个 Agent/skill 系统很可能已经在跑 Loop 1任务执行。试着加一个 Loop 2验证步骤。哪怕只检查「输出格式是否正确」或「是否有明显错误」。这是最低成本的可靠性提升。第二写评估用例哪怕只写 5 条。不需要一步到位写 72 个。问自己这个系统最可能在哪五种情况下出错把每种情况写成一条评估用例。每次改完代码跑一遍。第三图用于编排知识图按需使用。如果系统有多个 Agent 协作用 LangGraph 做编排图值得投入。但知识图GraphRAG只在确实有多跳查询和综合需求时才引入。大多数场景下向量搜索 结构化上下文就够了。本文基于 Dr. Maryam Mirami 视频「You Can Learn Loop Engineering, Graph Engineering in 18min」改写配图为视频截图 设计制图。原文视频可在 YouTube 观看。 AI Agent 工程化六层架构：从 Prompt 到 Production
AI Agent 工程化六层架构从 Prompt 到 Production读懂 Loop Engineering / Graph Engineering / Harness Engineering。以及它们为什么不是又一轮 buzzword 炒作。而是构建生产级 AI Agent 的真正基础。你最近大概在 X / Reddit / 技术博客上频繁撞见这几个词Loop Engineering、Graph Engineering、Harness Engineering、评估用例Evals。字面上看像又一轮造词运动。但 Dr. Maryam Miradi 在这支 18 分钟的视频里用一句话把它们拉下神坛They didnt go viral because they are complicated or magical. They are actually very simple building blocks.「它们能走红不是因为复杂或神奇。它们其实是非常简单的基础构件。」她用同一个保险理赔 Agent 系统从头穿到尾。把这六层讲明白了。本文是该视频的图文重构。保留关键洞见补上术语解释和中文语境下的迁移思路。0. 先从一个问题开始假设你已经用 LangGraph 搭了一套保险理赔 Agent 系统。5 个 Agent 协作。从理赔受理到最终赔付流程走完、图跑通了。然后你发现损伤程度明明是轻微系统却批准了 $4,500 赔付。五个 Agent 跑完了。图跑完了。答案还是错的。现在开发者必须手动检查每一条追踪记录。修改逻辑。然后重新跑整个流程。这就是这六个工程层要填补的缺口。1. Prompt Engineering → Context Engineering打地基最基础的起点写 prompt。给模型一个角色「你是一个专业的损伤文档助手」、任务、约束、输出格式。这是Prompt Engineering。定义一次交互应该长什么样。问题也很明显它是一次性的one-shot。你可以加 loop 和迭代。但它本身解决不了复杂问题。而且模型回答需要信息。所以你需要Context Engineering。Context Engineering 的关键动作把所有可用的信息塞进上下文。在保险理赔系统里就是保单policy、客户信息customer、事故细节incident、损伤描述damage。全部结构化地喂给模型。然后模型才能做损伤证据评估、保单决策、风险评估、赔付建议。但这引出一个新问题上下文窗口虽然越来越大模型在约 10% 窗口位置就开始「腐化」context rot。ChromaDB 的研究发现超过这个阈值模型错误率显著上升。Dr. Mirami 在她的进阶 Context Engineering 视频里讲了 7 种应对方法。上下文压缩compaction、Agent 即工具agent as a tool等。但根本局限还在We do not know for sure that the agent is going to do the task reliably.「我们无法确定 Agent 是否一定会可靠地完成任务。」你不知道 Agent 到底会不会可靠完成任务。所以需要下一层。2. Agent Execution Engineering定义「一个 Agent 怎么干活」这一层的关键问题一个 Agent 在所有情况下应该怎么行动以保险理赔受理 Agent 为例。围绕「接收理赔」这单一职责要做的事远比想象的多理赔类型 → 规范化 → 验证 → 声明依赖需求 → 从已验证字段构建证据 → 损伤证据存在性 → 自定义状态长度 → 既往理赔 → 迟报 → 置信度评估 → 受理完成 → 审计事件不是「一个 Agent 做一个任务」。而是确保这个 Agent精确地做业务要求它做的事。执行的引擎是ReAct 模式Reason推理→ Act行动→ Observe观察→ Feedback反馈→ Replan/Retry重规划/重试→ Stop完成时停止。但 Agent Execution Engineering 只定义了「一次尝试」怎么运作。如果那次尝试不够好呢3. Loop Engineering本文重点Loop engineering defines what happens when that attempt is not good enough.「Loop engineering 定义了当那次尝试不够好时该怎么办。」Loop Engineering 的定位当一次尝试不够好时系统应该做什么。评估什么继续什么重试多少次要不要人介入3.1 无 Loop vs 有 Loop无 Loop 的保险系统图理赔受理 → 损伤证据 → 赔付 → 人工审核 → 驳回/自动批准 → 结束每个节点只经过一次。决策在那一刻定型。加上 Loop 之后理赔受理 → 损伤尝试 (×1…20) → 循环评估 → 损伤循环决策 → 图构建器 → 评估 → 路由 → (返回损伤尝试 或 继续前进)关键差异损伤循环决策damage loop decision和路由节点router形成闭环。直到条件满足才往前走。这不仅仅是「加个 while 循环」。Loop Engineering 定义了多层反馈环的层次结构3.2 四层 LoopLoop 1任务执行环Task Action/Observation最基础的一层。每个 Agent 都在做这件事。执行任务、观察到结果。这一直都存在。不新鲜。Loop 2验证反馈环Verification → Feedback → Retry until criteria pass这是关键升级。任务做完后有一个独立的验证步骤评判结果是否达标。不达标就重试直到通过。这是 Critic、Evaluator、Self-healing、Human-in-the-loop 这些设计模式所在的位置。Loop 3事件驱动环Event-driven → Auto-update on new data系统不再「跑一次就停」。当新数据到达时自动重新运行并更新状态。这是一个持续自我更新的系统。Loop 4爬山改进环Hill-climbing → Multi-round pattern improvement最高层。不只是单次任务变好。而是从多轮反馈中提取模式改进未来的每一轮。这是系统在「学习」。3.3 Loop Engineering × 设计模式设计模式告诉你局部用什么反馈机制critic 批评者、evaluator 评估者、self-healing 自愈。Loop Engineering 告诉你反馈如何在整体 Agentic 系统中运作。横跨 Agent 执行、编排、管控、生产系统。无处不在。Dr. Mirami 用 Andrew Ng 的产品开发三层 Loop 做了进一步说明Loop速度做什么类比Agentic Coding Loop分钟级写代码→跑测试→浏览器检查→迭代直到满足 spec开发者在 IDE 里的内环Developer Feedback Loop10 分钟~2 小时Review 产品→给反馈→更新 spec 和优先级→回到 Loop 1团队代码审查 迭代External Feedback Loop小时~天~周使用数据用户反馈→调整产品方向A/B 测试 产品决策3.4 「Loop Engineering will surprise you」Dr. Mirami 开场说「loop engineering will surprise you」。她指的是It is everywhere from prompt engineering to production agent engineering. The shape of it will look different, but it is everywhere — to improve and use feedback as a pattern to make our agentic system better.「它无处不在从 prompt engineering 到 production agent engineering。形态各异但无处不在用反馈作为模式来改进让我们的 Agentic 系统变得更好。」Loop Engineering 不是某个特定技术。而是一种跨越所有层的反馈思维。4. Graph Engineering编排图 vs 知识图Graph Engineering 涉及两类图。用途完全不同4.1 Orchestration Graph编排图这是LangGraph 做的事。定义 Agent 之间的执行流理赔受理 → 损伤评估 → 评估 → 保单 → 风险 → 赔付 → 路由 → …每个节点是一个 Agent 或一个决策点。边是条件跳转。用 supervisor、aggregator、human approval 等模式做协调。但结构本身不保证可靠性。图跑通了不代表结果对了。4.2 Knowledge / Memory Graph知识/记忆图这是GraphRAGMicrosoft做的事分块 → 实体提取 → 社区检测 → 社区总结 → 生成答案Graph Memory 则是跟踪实体关系随时间的变化。例如「我在哪工作」这个事实是可能改变的。4.3 什么时候用 Graph什么时候不用用 Graph 的场景多跳查询、时序推理、需要综合多个信息源、时间敏感信息。不用 Graph 的场景简单单步查询、成本敏感、不需要跨实体推理、entity resolution 质量无法保证时。Bad entity resolution breaks multi-hop trust.「糟糕的实体解析会破坏多跳推理的可信度。」如果实体名称不完全一致比如「Maryam Miradi」vs「Dr. Mirami」多跳推理的可信度就会崩溃。Dr. Mirami 做了五年图分析欺诈检测。她的经验图计算非常昂贵应该用 lazy 策略。不要构建整个图只构建你需要的那部分。Use graph for orchestration always, but for knowledge always selectively.「编排图始终用但知识图要始终有选择地用。」5. Harness Engineering让 Agent 可控Harness Engineering 回答怎么让 Agent 和 Graph 的执行变得可靠、可控、可观测5.1 评估用例是重心Dr. Mirami 为保险理赔 Agent 写了72 个评估用例test_image_mismatch— 图片和理赔类型不匹配test_low_confidence_triggers— 低置信度触发人工审核test_risk_score_for_escalation— 风险评分是否触发升级test_invalid_policy_triggers_escalation— 无效保单触发升级test_excluded_coverage— 排除条款被触发test_payout_above_limit/test_payout_below_limit— 赔付金额越界每一个边界条件都有一条测试。测试即文档测试即护栏。5.2 Harness 的完整结构输入 → 入口验证 → Agent 编排 → 出口验证 → 输出 贯穿始终 ├── 运行时策略重试、超时、限流、熔断 ├── 可观测性日志、指标、仪表盘、告警 ├── 状态管理 ├── 审计追踪 ├── 人工介入点 └── 密钥管理6. Production Agent Engineering全部整合到这一层前面所有层融合为一个可用的业务系统。架构图用户和渠道 ↓ Agent 管控层第六层的所有东西 ↓ 企业工具和指南 ├── 安全 ├── 人工介入 ├── 部署 └── 监控和指标Dr. Mirami 在构建医疗 Agent 时用了同样的思路。5 个插件、LLM-as-a-Judge、13 条生产标准。Nowadays it is not anymore about what you built — because the code is getting faster and faster by Claude Code and Codex. Its more of: do we reach the point that businesses ask us to? Do we deliver on what they want?「如今的焦点不再是你构建了什么。因为代码产出因 Claude Code 和 Codex 越来越快。真正的问题是我们是否达到了业务的要求我们是否交付了他们真正想要的东西」代码产出越来越快。Claude Code、Codex 让写代码不再是瓶颈。真正的问题是系统是否达到了业务要求7. 对你的项目三个可立刻落地的点第一显式化反馈环。你的任何一个 Agent/skill 系统很可能已经在跑 Loop 1任务执行。试着加一个 Loop 2验证步骤。哪怕只检查「输出格式是否正确」或「是否有明显错误」。这是最低成本的可靠性提升。第二写评估用例哪怕只写 5 条。不需要一步到位写 72 个。问自己这个系统最可能在哪五种情况下出错把每种情况写成一条评估用例。每次改完代码跑一遍。第三图用于编排知识图按需使用。如果系统有多个 Agent 协作用 LangGraph 做编排图值得投入。但知识图GraphRAG只在确实有多跳查询和综合需求时才引入。大多数场景下向量搜索 结构化上下文就够了。本文基于 Dr. Maryam Mirami 视频「You Can Learn Loop Engineering, Graph Engineering in 18min」改写配图为视频截图 设计制图。原文视频可在 YouTube 观看。