从Prompt/Context/Harness梳理到Agent工程理解#架构 #AI #AGENT #总结目录核心认

#架构 #AI #AGENT #总结

文档性质：个人深度思考与理解总结
整理时间：2026 年 3 月 24 日
核心视角：从三层概念演进推导 Agent 工程的本质认知

核心认知框架
三层概念的演进逻辑
技术本质：概率性系统的工程约束
方法论定位：包含关系 vs 观察维度
[业务理解：Agent 工程的第一性原理](#五业务理解 agent 工程的第一性原理)
[理解深化：从三层概念到 Agent 工程实践](#六理解深化从三层概念到 agent 工程实践)
[终极认知：Agent 工程的成熟形态](#七终极认知 agent 工程的成熟形态)

1. 核心认知框架

1.1 终极公式

在梳理 Prompt/Context/Harness 的过程中，我得出 AI 智能体工程的第一性原理公式：

\text{任务成功} = \underbrace{\text{业务本质理解}}_{\text{方向(What/Why)}} \times \underbrace{(\text{Prompt} + \text{Context} + \text{Harness})}_{\text{执行(How)}} \times \underbrace{\text{模型能力}}_{\text{基座(Capacity)}}

⚠️ 注意：这是乘法关系，任一维度为 0，结果即为 0

1.2 三层核心定义

层级	核心问题	我的理解定义	类比
Prompt	说什么？	跟 AI 怎么说话	给司机的目的地指令
Context	知道什么？	给 AI 什么信息	给司机的地图和路况
Harness	什么条件？	在什么环境里做事	交通规则 + 护栏 + 保险 + 导航系统

1.3 认知层级金字塔

2. 三层概念的演进逻辑

2.1 时间线演进：认知负荷的释放

2.2 演进驱动力：隐性知识显性化

阶段	隐性知识	显性化概念	分离原因
Prompt 时代	"多给几个例子模型输出更好"	Few-shot Prompting	任务简单，无需分离
Context 时代	"把相关文件塞进去模型更准"	RAG/向量检索	多轮对话复杂化
Harness 时代	"得有个东西管着模型别乱来"	Hooks/状态机	生产环境可靠性需求

2.3 概念分离的本质

概念分离不是技术升级，而是认知负荷管理的必然选择。

早期：单一概念承载所有
┌─────────────────────────────────────────────────────────────────┐
│              Prompt Engineering (2022-2024)                      │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • 指令措辞  • 上下文管理  • 流程控制  • 错误处理        │    │
│  └─────────────────────────────────────────────────────────┘    │
│  问题：概念过载，开发者难以同时关注所有维度                       │
└─────────────────────────────────────────────────────────────────┘
                          ↓ 任务复杂度提升
后期：概念分离降低认知负荷
┌─────────────────────────────────────────────────────────────────┐
│  Prompt          Context          Harness                        │
│  ┌─────────┐    ┌─────────────┐   ┌─────────────────────────┐   │
│  │指令措辞  │    │信息检索注入  │   │流程编排  钩子验证       │   │
│  │格式约束  │    │记忆管理     │   │多智能体  错误恢复       │   │
│  │Few-shot │    │Token 优化   │   │状态管理  安全约束       │   │
│  └─────────┘    └─────────────┘   └─────────────────────────┘   │
│  优势：每层专注单一维度，降低认知负荷，便于专业化                 │
└─────────────────────────────────────────────────────────────────┘

3. 技术本质：概率性系统的工程约束

3.1 技术根因链条

三层方法论的产生遵循清晰的技术因果链：

┌─────────────────────────────────────────────────────────────────────────┐
│                    三层方法论的技术根因链条                              │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │              根因：Transformer 架构本质                          │   │
│   │              • 无状态性 (Stateless)                             │   │
│   │              • 注意力衰退 (Attention Decay)                     │   │
│   │              • 概率输出 (Probabilistic Output)                  │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                              ↓                                          │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │              表象：当前主流交互形态                              │   │
│   │              • HTTP/REST 请求 - 响应模式                         │   │
│   │              • Token 窗口物理限制                                │   │
│   │              • 无持久连接状态                                    │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                              ↓                                          │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │              应对：三层工程方法论                                │   │
│   │              • Prompt → 意图清晰化                               │   │
│   │              • Context → 信息完备化                              │   │
│   │              • Harness → 执行可靠化                              │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│   核心结论：HTTP 只是表象，Transformer 概率性本质才是根因                │
│   因此无论协议如何变化（WebSocket/MCP/gRPC），三层方法论依然适用         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

3.2 根因与工程影响映射

技术根因	交互表象	工程挑战	对应层级
Transformer 无状态性	HTTP 无状态请求	需要外部状态管理	Harness
注意力机制衰退曲线	Token 窗口限制	需要信息优先级管理	Context
概率输出本质	同一输入不同输出	需要验证与纠错机制	Harness
意图理解偏差	自然语言歧义	需要清晰指令表达	Prompt

3.3 本章核心总结

┌─────────────────────────────────────────────────────────────────────────┐
│                    技术本质总结                                          │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   根因层          表象层          方法论层                               │
│   ┌───────┐      ┌───────┐      ┌─────────────────┐                    │
│   │Transformer│ →  │ HTTP  │ →  │ Prompt/Context/ │                    │
│   │概率性本质 │    │交互形态│    │    Harness      │                    │
│   └───────┘      └───────┘      └─────────────────┘                    │
│                                                                         │
│   理解要点：                                                            │
│   • 根因决定方法论的持久性（协议变化不影响三层）                        │
│   • 表象决定方法论的具体实现（HTTP/MCP 只是传输方式）                    │
│   • 方法论是根因与表象之间的工程桥梁                                    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

4. 方法论定位：包含关系 vs 观察维度

4.1 两种视角的统一

视角	适用场景	核心问题	思考方式
包含关系	系统设计、架构实现	"数据如何组织？"	嵌套集合（俄罗斯套娃）
观察维度	问题诊断、优化分析	"问题出在哪里？"	多维分析（三棱镜分光）

4.2 为什么需要观察维度视角

包含关系无法解释以下现象：

现象	包含关系视角	观察维度视角
弱 Prompt + 强 Harness = 成功	矛盾（基础层差为什么成功）	Harness 可以补偿 Prompt
强 Prompt + 弱 Harness = 失败	矛盾（包含了为什么失败）	Harness 缺陷可抵消 Prompt 优势
同一数据不同效果	无法解释	Harness 维度不同导致

4.3 三维坐标系模型

4.4 统一认知框架

┌─────────────────────────────────────────────────────────────────────────┐
│                    AI 工程三层认知框架                                   │
├─────────────────────────────────────────────────────────────────────────┤
│  技术实现 → 包含关系（Harness ⊃ Context ⊃ Prompt）                      │
│           这是数据组织结构的客观事实                                     │
├─────────────────────────────────────────────────────────────────────────┤
│  问题诊断 → 观察维度（Prompt/Context/Harness 三维分析）                  │
│           这是优化迭代的分析工具                                         │
├─────────────────────────────────────────────────────────────────────────┤
│  系统优化 → 协同关系（三层平衡 + 相互补偿）                              │
│           这是达到最优的实践原则                                         │
└─────────────────────────────────────────────────────────────────────────┘

5. 业务理解：Agent 工程的第一性原理

5.1 核心公式

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   任务目标 > 业务理解编排 + Prompt/Context/Harness 具体实现 = 最终结果   │
│                                                                         │
│   ┌────────────────┐    ┌─────────────────────────────────────────┐     │
│   │   业务理解     │ +  │  Prompt + Context + Harness 实现组织    │     │
│   │   (方向)       │    │  (执行)                                 │     │
│   └────────────────┘    └─────────────────────────────────────────┘     │
│                                                                         │
│   ⚠️ 业务理解是前置条件，决定技术投入的方向和回报率                       │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

5.2 DDD 思维框架的启发式借鉴

核心定位：DDD 是思维框架，不是实现模板。我们借鉴的是 DDD 理解业务的思维方式，而非直接套用其技术实现。

┌─────────────────────────────────────────────────────────────────────────┐
│                    DDD 思维框架的启发式借鉴                              │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   我们借鉴什么？                  我们不借鉴什么？                       │
│   ┌─────────────────────┐        ┌─────────────────────┐                │
│   │ • 限界上下文的边界  │        │ • 确定性的事务保证  │                │
│   │   思维              │        │ • 明确的失败定义    │                │
│   │ • 聚合根的核心聚焦  │        │ • 固定的数据模型    │                │
│   │ • 领域服务的编排    │        │ • 确定性的执行逻辑  │                │
│   │   思路              │        │                     │                │
│   └─────────────────────┘        └─────────────────────┘                │
│                                                                         │
│   关键差异：传统软件追求确定性，AI Agent 需要管理不确定性                │
│                                                                         │
│   正确使用方式：                                                        │
│   1. 用 DDD 思维帮助理解业务边界和核心目标                              │
│   2. 将理解转化为 Prompt/Context/Harness 的具体策略                      │
│   3. 实现时必须适配 AI 的概率性本质，而非直接套用 DDD 技术模式            │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

5.3 思维框架参考表

DDD 思维	传统软件实现	AI Agent 启发式借鉴	适配要点
限界上下文	微服务边界	思考 Agent 能力边界	边界是概率性的，需置信度管理
聚合根	核心数据对象	思考核心任务目标	目标是动态演变的
实体/值对象	数据模型	思考上下文信息单元	信息需要优先级排序
领域服务	业务逻辑代码	思考编排策略	逻辑是概率性执行的
仓库	数据库访问	思考 RAG/记忆检索	检索结果需要验证

使用原则：

DDD 的价值在于帮助思考，而非提供答案。用 DDD 的思维方式理解业务，但实现时必须根据 AI 的概率性本质进行调整。

6. 理解深化：从三层概念到 Agent 工程实践

基于对 Prompt/Context/Harness 的梳理，我对 Agent 工程实践形成以下理解总结。这并非确定的操作手册，而是对当前工程实践的反思性认知。我认为，Agent 工程的核心在于从“线性执行”转向“动态闭环”。

6.1 实践框架的理解：从线性执行到动态闭环

传统的软件工程是确定性的线性执行，而 Agent 工程是基于三层概念的动态闭环。我将之前的“四步探索”与“动态互动”结合，形成以下的动态闭环实践框架：

┌─────────────────────────────────────────────────────────────────────────┐
│                 Agent 工程动态闭环实践框架 (整合版)                       │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   【阶段一：业务本质理解】(方向锚定)                                      │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │ • 梳理 SOP  • 定义"不可做清单"  • 识别关键决策点                  │   │
│   │ 核心反思："这个任务如果由人类专家做，他会思考什么？"              │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                              ↓                                          │
│   【阶段二：编排策略思考】(三层映射)                                      │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │ • 将业务流程映射为 Agent 工作流                                   │   │
│   │ 核心反思："哪里需要 Prompt？哪里需要 Context？哪里需要 Harness？" │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                              ↓                                          │
│   【阶段三：动态执行与交织】(运行时闭环)                                  │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │              三层概念的实时动态互动                                │   │
│   │  ┌─────────┐     ┌─────────────┐     ┌─────────────────────┐    │   │
│   │  │ Prompt  │ ↔   │   Context   │ ↔   │      Harness        │    │   │
│   │  │ (意图)  │     │  (信息)     │     │    (约束/流程)      │    │   │
│   │  └─────────┘     └─────────────┘     └─────────────────────┘    │   │
│   │         ↖_______________↙_______________↗                       │   │
│   │                    实时反馈与调整                                │   │
│   │  • Prompt 根据 Context 动态调整措辞                                │   │
│   │  • Context 根据 Harness 状态动态注入信息                           │   │
│   │  • Harness 根据 Prompt 输出动态触发钩子                            │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                              ↓                                          │
│   【阶段四：可观测性与持续反思】(进化驱动)                                │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │ • Trace：还原决策路径 (黑匣子)                                    │   │
│   │ • Eval：量化可靠性 (标尺)                                        │   │
│   │ • 持续反思：哪些假设被验证？哪些需要调整？                        │   │
│   │ 输出 → 反馈至 [阶段一] 重新校准业务理解                           │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│   核心理解：                                                            │
│   • 前两步是"设计时"的静态规划                                          │
│   • 第三步是"运行时"的动态交织 (核心差异点)                             │
│   • 第四步是"进化时"的闭环驱动                                          │
│   • 整体构成一个螺旋上升的认知与实践闭环                                │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

6.2 对“可观测性与评估”的深度理解

在梳理过程中，我深刻意识到：没有可观测性的 Agent 工程是盲目的。它不仅仅是第四步，更是贯穿整个闭环的神经系统。

Trace (链路追踪)：不仅是记录日志，更是还原模型决策路径的“黑匣子”。它让我们看到 Prompt 如何被 Context 影响，Harness 如何干预输出。
Eval (评估框架)：不仅是测试通过率，更是量化“概率性系统”可靠性的标尺。它迫使我们从“感觉不错”转向“数据证明”。
Governance (治理)：不仅是成本控制，更是对 AI 行为边界的持续校准。

反思：很多团队在原型阶段忽视这些，导致进入生产后无法诊断问题。我认为，可观测性应被视为 Harness 的核心组成部分，而非附加功能。

6.3 对“构建优先级”的阶段性理解

随着对三层概念理解的深入，我对不同阶段的优先级有了新的看法：

阶段	传统视角	我的理解与反思
原型验证	Prompt 优先	反思：虽然 Prompt 见效快，但若完全忽视 Harness 的基本约束，原型可能建立在虚假的可靠性上。建议最小化 Harness（如基础重试）。
小批量使用	Context 优先	反思：此时 Context 的质量决定一致性，但需警惕“信息过载”导致的注意力衰退。Context 的筛选策略比数量更重要。
生产部署	Harness 优先	认同：在生产环境，可靠性压倒一切。Harness 的完善程度直接决定系统的生存能力。Eval 必须同步上线。

6.4 对“问题诊断”的理解重构

当任务失败时，不应机械地按顺序检查，而应基于三层互动关系进行诊断：

是意图偏差吗？ (Prompt 层) -> 检查指令是否清晰，Few-shot 是否误导。
是信息缺失或干扰吗？ (Context 层) -> 检查 RAG 检索准确性，是否有噪声干扰注意力。
是约束失效吗？ (Harness 层) -> 检查状态机是否流转错误，Hooks 是否未触发，重试机制是否陷入死循环。
是业务理解偏差吗？ (根本层) -> 检查是否一开始就定义了错误的任务目标或边界。
是观测盲区吗？ (支撑层) -> 检查是否因为缺乏 Trace 而无法定位真实原因。

核心观点：诊断过程本身就是一个不断修正对三层理解的过程。

7. 终极认知：Agent 工程的成熟形态

通过对 Prompt/Context/Harness 的层层梳理，我对 Agent 工程的终极形态形成了以下核心认知。

7.1 三层方法论的本质再定义

Prompt/Context/Harness 是基于 LLM 概率性系统本质约束而演化出的工程方法论。

维度	我的认知定位
技术属性	实践分层，非技术分层
时间属性	当前最优，非永恒真理
关系属性	演进积累，非替代关系

7.2 技术根因的再确认

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   Transformer 概率性本质  →  HTTP 交互形态  →  三层工程方法论             │
│         (根因)                 (表象)            (应对)                  │
│                                                                         │
│   理解要点：                                                            │
│   • 根因决定方法论的持久性（协议变化不影响三层）                        │
│   • 表象决定方法论的具体实现（HTTP/MCP 只是传输方式）                    │
│   • 方法论是根因与表象之间的工程桥梁                                    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

7.3 核心认知的升级对照

常见误区	我的理解升级
三层是独立技术模块	三层是同一问题的三种抽象粒度，相互渗透
追求单层极致优化	追求三层协同的动态平衡
技术驱动优先	业务理解驱动优先，技术服务于业务边界
模型能力决定上限	工程方法论（三层编排）决定下限和稳定性
HTTP 是根因	概率性系统本质是根因，HTTP 仅是表象
DDD 可直接套用	DDD 是思维框架借鉴，需适配概率性本质
可观测性是可选插件	可观测性是生产级 Agent 的神经系统
实践指导是确定的	实践是探索性的，需持续验证和迭代

7.4 不变的核心原则

无论技术如何演进，以下原则是我认为 Agent 工程必须坚守的：

原则	说明
意图清晰化	人类意图必须转化为模型可精确理解的形式 (Prompt)
信息完备化	模型必须在足够的上下文信息中决策 (Context)
执行可靠化	概率输出必须经过工程约束才能交付 (Harness)
持续评估化	系统必须通过可观测性数据驱动迭代 (Eval)

7.5 终极目标：让用户感觉不到三层的存在

这是我梳理全文后得出的最重要结论：

Agent 工程的终极目标：让用户感觉不到 Prompt、Context 和 Harness 的存在。只感受到： • 任务的可靠完成 • 成本的可控优化这正是工程成熟的标志：基础设施越完善，用户感知越简单（就像用户用电时不需要理解发电机原理，只需要灯亮一样）。最好的 Agent 工程，是让复杂的三层编排“隐形”，只留下可靠的结果。

7.6 最终定位与自我期许

最好的 AI 工程师不是最会写 Prompt 的人，而是最懂业务、最能将业务逻辑转化为 Prompt/Context/Harness 编排策略的系统架构师。

本文档的价值在于：

梳理逻辑：厘清三层概念的演进脉络和技术根因。
提供框架：建立从业务理解到技术实现的思考模型。
避免误区：警惕过度工程化、技术唯上和确定性思维陷阱。
明确方向：确立以“用户无感”为终极目标的工程演进方向。
保持开放：承认实践的探索性本质，随时准备修正认知。

Agent 工程仍在高速发展，今天的理解可能在明天被刷新。但回归业务本质、尊重概率特性、追求可靠交付的核心逻辑，将是我持续探索的指南针。