[AI/Agent/概念辨析] AI Agent 演进范式：Prompt 工程 => Context 工程 => Agent Loop 工程 => Hardness 工程

1 AI Agent 演进范式：Prompt 工程 => Context 工程 => Hardness 工程

概念概述与引入背景

  • 在 AI Agent 架构演进的过程中，针对如何提升大语言模型（LLM）执行复杂任务的能力，业界经历了从提示词调优（Prompting）到上下文治理（Context Window Management），再到确定性控制与硬化（Agent Hardness Standard & Engineering）的三代技术范式的迭代。

  • Prompt 工程（1.0 时代）：侧重于“如何用更好的文本表达”来激活大模型潜能。

提示词工程(Prompt Engineering): 通过设计输入给模型的“任务、目标、约束、示例与行为规则”，把人的意图转换成模型可执行指令的工程。

  • Context 工程（2.0 时代）：侧重于“如何在有限且动态的上下文窗口中”进行记忆、工具状态与多轮对话的精准调度。

Context Engingnnering/上下文工程，就是在 AI Agent 每一次决策/行动之前，动态构造一份“足以让模型做出正确决策”的最小信息环境。
Context Engineering = 为 AI Agent 的每一次推理，动态构造“正确的信息环境”。
其解决的核心问题：在【模型】有限的【认知带宽】下，让 AI Agent 在正确的时间获得正确的信息，并避免错误、过时、冲突和冗余的信息干扰决策。这比“【管理 Prompt】”要本质得多。业界目前也基本从 Prompt Engineering 转向了对整个模型输入状态的工程化管理：系统指令(System Prompt)、任务(Task)、历史(History)、记忆(Memory)、知识(Knowledge)、工具(Tool)、工具结果(Tool Result)、运行状态(Running Status)等，都属于上下文的一部分。

  • Hardness 工程（3.0 时代）：侧重于“如何将不可控的概率性 LLM”封装为具备工业级可靠性（Reliability）、鲁棒性（Robustness）和确定性（Determinism）的硬核 Agent 框架。
  • 定义:

Hardness 工程是针对 AI Agent 系统的不确定性进行“工业级防摔与可靠性约束”的系统工程。
它通过显式状态机（FSM/DAG）、确定性代码控制、强类型校验（Guardrails）、异常熔断与人机协作（HITL），将概率性的大语言模型（LLM）“包裹”并硬化为具备 SLA（服务级别协议）保障、可确定、可中断、可恢复 的生产级软件系统。

  • 定位:

系统的防护骨骼：如果 Prompt 是 Agent 的“语言表达”，Context 是 Agent 的“动态记忆”，那么 Hardness 工程就是 Agent 走出实验室 Sandbox、进入生产环境所必需的“防护外骨骼”。
概率与确定性的桥梁：它是连接“不可控的 LLM 概率推理”与“高容错要求的工业级业务系统”之间的确定性控制层。

核心维度对比分析

对比维度 Prompt 工程 (Prompt Engineering) Context Engineering (上下文工程) Hardness Engineering (硬化工程)
提出时间/代表组织 2022-2024 (OpenAI / Anthropic / 学术界) 2025 (LangChain / LlamaIndex / AutoGPT 社区) 2026-(微软 AutoGen / CrewAI / 工业界落地团队)
提出背景 从 Zero-Shot 到 Few-Shot，研究者发现输入文本的结构对 LLM 输出质量影响巨大 Agent 引入 Tool Use 和多轮对话后，Token 消耗剧增、长上下文引发“中间失忆（Lost in the Middle）” Agent 走出 Sandbox 进军生产环境，遇到死循环、Tool 调用不稳定性、幻觉导致的不可控风险
解决的核心问题 教模型怎么做：解决 LLM 对意图理解不精准、零样本输出不稳定问题
（【指令意图】）		 给模型看什么：解决记忆保留、长文本检索（RAG）、Tool schema 注入与动态剪枝问题
（【有限窗口下，对输入信息集合的聚焦】）		 系统出错了怎么办：解决 AI Agent 系统在工业落地时的不可靠、无法中断、不可重试、状态不透明问题
（【运行时异常与边界（可靠性、鲁棒性、确定性）】）
解决的域 语义理解、输出约束 信息供给、窗口管理 故障、对抗、边界、工具失败、失控风险
产出物 角色设定、Few‑shot、CoT 指令、输出格式模板 RAG 策略、记忆策略、上下文截断 / 排序 / 过滤规则、... 参数校验、重试降级、死循环检测、输入防御、结果校验、异常兜底逻辑
核心优势 轻量化、零代码/低代码、迭代成本极低 大幅拓展 Agent 复杂推理能力与外部知识检索能力 赋予 Agent 工业级确定性、SLA 保障、自我纠错与长生命周期运行能力
局限性与风险 极易受模型更新影响（提示词敏感）、上限较低 上下文噪声干扰（Context Pollution）、Token 成本高昂、延迟增加 架构复杂度极高、过度硬化可能抑制 Agent 的泛化推理能力（Over-engineering）
适用场景 单次任务、简单分类、客服草稿生成、简单 SQL 生成 复杂的多轮对话系统、基于文档的 Knowledge QA、工作流初级编排 金融交易 Agent、自动化 DevOps、医疗诊断辅助、复杂 RPA 替代等高风险生产场景

架构演进与演进拓扑

这三个工程范式并非互斥关系，而是层层递进、向下包含的栈式架构：

graph TD A[Hardness 工程: 状态机, 重试机制, 人机协作, 安全沙箱] --> B[Context Engineering: 动态窗口, RAG, 记忆压缩, 状态管理] B --> C[Prompt Engineering: CoT, Few-Shot, System Prompt, 角色定义] C --> D[LLM 基础模型] style A fill:#f9f,stroke:#333,stroke-width:2px style B fill:#bbf,stroke:#333,stroke-width:2px style C fill:#dfd,stroke:#333,stroke-width:2px

本质区别与关联 + 关系图 （必读）

  • 关系图
erDiagram PROMPT_工程 { string object "指令文本：角色、约束、Few‑shot、CoT、输出Schema" string goal "解决：意图理解、输出格式、推理引导" string limit "仅处理指令，不处理信息供给、运行异常" } CONTEXT_工程 { string object "上下文全集：对话记忆、RAG片段、工具返回、状态" string goal "解决：信息供给、窗口管理、降噪、长上下文遗忘" string limit "信息准备完毕，无法防止运行时故障" } HARDNESS_工程 { string object "全链路校验、重试、降级、循环检测、输入防御" string goal "解决：异常、边界、对抗、工具失败、Agent失控" string limit "不改变模型指令与输入事实，管控运行风险" } PROMPT_工程 ||--o{ CONTEXT_工程 : "组合，共同构造LLM请求输入" PROMPT_工程 }|--|| HARDNESS_工程 : "依赖兜底；Prompt再好也会遇到现实异常" CONTEXT_工程 }|--|| HARDNESS_工程 : "依赖兜底；上下文完备不能避免运行报错"

  • 关联关系：Prompt 是 Context 中的基本构成单元；Context 为 Prompt 提供了历史与状态容器；Hardness 则是围绕 Prompt 和 Context 构建的防摔保护壳与自动化运行保障框架。

  • 本质区别：

  • Prompt 工程本质是 NLP 领域的文本工程；

  • Context 工程本质是 内存/缓存管理工程（AI 界的虚拟内存管理）；

  • Hardness 工程本质是 传统系统工程（Systems Engineering）与可靠性工程（SRE） 在 AI 领域的延伸。

最佳实践指南

1. Prompt 工程最佳实践

  1. 模块化、模板化：分离 System Prompt（角色、全局约束、输出格式）和 User Prompt（用户实际 query）；
  • 模块化、模板化：采用 XML 标签或 JSON 结构分隔指令（如 <instructions>, <context>, <constraints>）。
  1. 复杂任务强制 CoT 思维链，必要时 Few‑shot 提供正确 + 错误样例；
  • 思维链引导：引入 CoT（Chain-of-Thought）或 ReAct（Reason + Act）结构，强制模型在输出 final answer 前给出思考过程。
  1. 强约束输出 Schema，优先使用结构化输出（JSON 模式），减少自由文本解析；
  2. Prompt 做版本管理，配套评测集，不凭感觉写 Prompt；
  3. 不要把大量业务原始数据塞进 Prompt 本体，业务数据交给 Context 层处理。

2. Context 工程最佳实践

  1. 分层管理上下文：系统固定上下文、RAG 检索上下文、会话短期记忆、长期向量记忆，区分不同生命周期；

分层化、结构化 Context 压栈：将环境状态、可用工具描述（JSON Schema）与运行时变量分层隔离，避免上下文污染。

  1. 做上下文预处理：过滤无关片段、重排、去重、压缩(摘要)，不要无脑把全部检索结果塞窗口；

滑动窗口与摘要归档：使用 Rolling Window 策略保存最新 N 轮对话，结合后台异步 LLM 对长历史进行 Summary 归档。

  1. 长上下文策略：摘要压缩、滑动窗口、重要性打分裁剪，避免窗口溢出；

  2. 工具返回结果必须做清洗之后再放回上下文，不要直接把工具的原始脏输出喂给 LLM；

  3. 控制信息顺序：高优先级事实靠前，减少位置偏见。

3. Hardness 工程最佳实践

  1. 确定性状态机（FSM）结合：不全权依赖 LLM 做下一步路由，使用 DAG 或有限状态机约束 Agent 转移逻辑（如 LangGraph 范式）。
  2. Agent 状态层：循环检测，限制最大迭代轮次，防止死循环；状态持久化，失败可恢复；
  3. 工具层：入参校验，禁止直接把 LLM 输出当参数调用；工具异常捕获，重试、降级、超时控制；
  4. 输入防御层：用户输入做风险过滤，防止 Prompt 注入、越权诱导；
  5. 输出校验层：对 Agent 输出、工具调用计划做后置校验，不符合规则直接拦截兜底；

Guardrails 与 Circuit Breakers（熔断机制）：设置死循环拦截器、最大 Token/Step 阈值以及输出 Schema 校验器（如 Pydantic/Instructor），校验失败触发自动重试或 fallback机制。

  1. 边界 case 构造测试集：异常 query、工具报错、缺失信息、对抗输入做专项测试；
  2. 可观测：记录 Agent 决策链路、失败原因，便于定位是 Prompt 问题、Context 噪声还是 Hardness 缺失。

小结：整体组合最佳实践流程

用户 Query
→ 输入防御 (Hardness)
→ Context 组装 (检索、记忆、过滤、压缩)
→ Prompt 组装 (指令 + Schema)
→ LLM 调用
→ 解析 Agent 计划
→ 参数校验 (Hardness)
→ 工具执行
→ 结果清洗回写 Context；

循环受最大轮次限制；任意环节异常触发降级兜底 (Hardness)。

发展趋势

  1. 代码即控制层（Code-as-Architecture）：从 Prompt 式的自然语言控制，全面转向利用严格类型检查的代码（TypeScript/Python）定义 Agent 工作流。
  2. Context 自动化剪枝与 KV-Cache 优化：硬件级与引擎级（如 vLLM）对长上下文进行 Chunk 优化，结合 Agent 级别的注意力遮蔽，实现百万 Token 级 Context 的高效调度。
  3. Human-in-the-loop (HITL) 标准化：Hardness 工程将进一步推进“人机协作中断点”的标准规范化，高风险操作默认请求人工审批（Approval Gate）。

Z FAQ for 进阶篇

Q: 在设计 AI Agent 时，为什么只做 Prompt 工程无法满足生产落地要求？

  • Prompt 工程仅解决了模型“单次输出质量”的问题。但在生产环境中，AI Agent 需要面对复杂工具交互、长历史多轮对话以及异常情况。
  • 没有 Context 工程会导致模型因上下文超限或失忆而失效；
  • 没有 Hardness 工程会导致模型陷入【死循环】、产生【非法 API 调用】或【无法实现状态恢复与事务一致性】。

Q: 什么是上下文污染（Context Pollution）？如何解决？

  • 上下文污染指将不相关、冗余或冲突的信息注入 Context 窗口，导致 LLM 注意力分散、推理能力下降或产生幻觉。
  • 解决方法包括：使用 Vector DB 精准检索（RAG）、建立工具调用的过滤与剪枝机制、定期对历史对话进行【语义压缩】（Summarization）。

Q: Hardness 工程中的“熔断与重试（Circuit Breaking & Retry）”策略是如何设计的？

  • 当 Agent 连续调用工具失败或输出格式不符合 JSON Schema 时，Hardness 机制会捕获该异常，拼接具体的 Error Log 重新注入 Context 进行自我纠错；若重试达到上限（如 3 次），熔断器触发，切断当前 Agent 路径并回滚状态，降级由备用 Agent 执行或推送到 Human-in-the-loop(HITL) 人工干预队列。

Q: 请简述 ReAct 模式在 Prompt 与 Context 工程中的不同侧重点。

  • 在 Prompt 工程中，ReAct 侧重于系统提示词的设计（如要求模型按 Thought -> Action -> Observation 的格式流式输出）；
  • 在 Context 工程中，ReAct 侧重于将 Observation 的返回结果结构化追加回 Context Window，并及时清理陈旧的观察结果以节省 Token。

Q: 如何评价 LangChain 与 LangGraph 在 Hardness 工程上的差异？

  • 早期 LangChain 基于无状态/简单链式调用，控制权主要交给 LLM，容错能力较弱（Hardness 低）；
  • 而 LangGraph 引入了显式图结构（DAG/FSM）与持久化 Checkpoint 机制，允许 AI Agent 状态挂起、分支回溯与状态恢复，是 Hardness 工程的具体落地。

Q: Context Engineering 和传统 RAG 的关系是什么？

  • RAG 是 Context Engineering 的一个子集。
  • Context Engineering 不仅包含从外部数据库检索知识（RAG），还包括对话历史管理、内存级 Cache 调优、Tool/Function Schema 的动态构建与剪枝、以及 Working Memory 的更新策略。

Q: Hardness 工程如何保障 Agent 调用外部系统的安全性？

  • 采用双层 Guardrails：
  • 输入层校验 Agent 产生的 API 参数（如 SQL 注入防御、敏感词过滤）；
  • 运行层使用【容器隔离】（Docker/Wasm）执行代码，并针对涉及【系统修改】（如删除文件、发起支付）的步骤，通过 Hardness 框架【强行阻断】、并【等待人类确认】。

Q: 什么是“Lost in the Middle”现象？在 Context 工程中如何应对？

  • Lost in the Middle : 指 LLM 在处理超长上下文时，倾向于关注开头和结尾的信息，容易忽略位于长上下文【中间】的关键事实。、

  • 应对方案包括：

  • 重排（Rerank）检索到的上下文，将最关键的信息放在紧邻 Prompt 末尾（User Query 之前）或开头位置；
  • 剔除无关段落。

Q: 在构建 Agent 时，如何权衡 Agent 的灵活性（Flexibility）与硬度（Hardness）？*

  • 遵循“关键路径硬化，泛化推理自由”原则。

在涉及业务逻辑边界、安全安全风控、多系统协同的状态转移节点使用硬编码/状态机（高 Hardness）；
在具体的子任务解析、文本生成、灵活格式转换时给予 LLM 充足的 Reasoning 空间（高 Flexibility）。

Q: 未来 Agent 框架的发展会淘汰 Prompt 工程吗？

  • 不会淘汰，但 Prompt 工程的重要性会向底层下沉（从应用开发演变为系统基础设施中的 Prompt 模版优化）。上层开发者将越来越少直接撰写复杂的 Prompt，而是通过 Hardness 框架声明 Workflow 和 Tool Set，框架会自动拼装最佳的 Context 与系统 Prompt。

Y 推荐文献 *

X 参考文献

posted @ 2026-08-31 16:30  数据知音  阅读(47)  评论(0)    收藏  举报