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 didn't 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 四层 Loop

Loop 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 Loop	10 分钟~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（知识/记忆图）

这是 GraphRAG（Microsoft）做的事：

复制代码

 分块 → 实体提取 → 社区检测 → 社区总结 → 生成答案

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. It's 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 观看。