Ethan's Notes

Appearance

一、核心定义和边界 ​

  • 核心定位：Prompt 是指令层，解决“怎么指挥模型”，核心目标是缩小模型的搜索范围，将其行为收敛在业务流程内；Context 是供给层，解决给模型看什么，怎么看，核心目标是在有限的 Token 预算内，构建一个高信噪比的上下文；Harness 是执行控制层，解决“系统怎么持续执行、纠偏、观测与恢复”，核心目标是让系统在真实执行中不乱做、做得对、出错能快速止损和恢复。
  • 核心职责
    • 提示词工程：角色定义，任务拆解，输出格式，安全边界，少样本示例等等
    • 上下文工程：系统规则，任务目标，检索信息，历史摘要，工具上下文（工具 Schema 和工具执行结果的装配），上下文预算（裁剪和排序）
    • Harness 工程 ：信息边界，工具系统，记忆与状态，编排执行，可观测与评估，约束、校验、反馈与恢复

二、商业场景下的矛盾转移逻辑 ​

为什么长链路、低容错、可执行的商业场景，主要矛盾会从 Prompt/Context 转向 Harness？ ​

在玩具级或 Demo 级 Demo 场景中，写几个精妙的 Prompt、挂一个简单的 RAG（Context）就能让系统表现得非常智能。但到了低容错、可执行的商业场景（如外卖退款、机票退改签、金融转账等），主要矛盾必然发生转移，原因在于：

  1. 核心追求的变化：
    • 商业场景的核心追求不是“让模型答得多么有文采、多么像真人”，而是**“让系统在真实执行中不乱做、做得对、出错能快速限损和恢复”**。
  2. 大模型的本质缺陷：
    • 大模型本质上是一个“静态且不可控的下一个 Token 生成器”。它没有手脚（工具）、没有记忆（持久状态）、没有物理世界校验反馈，甚至它自己都不知道自己答错了。
  3. 系统崩溃点的转移：
    • 决定一个商业级 Agent 能否上线的，往往不是大模型推理错误（可以通过后端强校验拦截），而是外围系统的脆弱性——比如工具接口调用超时、数据库状态与模型理解不一致、历史长会话中发生上下文污染、由于模型误判导致的高危接口越权执行等。
    • 因此，“Agent = Model + Harness” 成为业界共识。模型只负责“提供思考和调用倾向”，而 Harness 负责把这次推理包装成一条稳定、安全、可观测、可熔断的生产级执行链路。

三、 如何具体做好这三个工程 ​

1. 如何做好提示词工程 (Prompt Engineering) ​

提示词工程的目标是缩小模型的搜索范围，将其行为收敛在业务轨道内：

  • 四要素拆分（Role-Task-Context-Format）：
    • Role：定义清晰的角色（如“苍穹外卖智能客服助手”）。
    • Task：明确单步动作，禁止模型“自作主张”。
    • Context：划定信息边界，告知“只能基于所给的 Context 回答，不知道就说抱歉”。
    • Format：约束输出格式，工程上必须要求模型输出强类型结构（如 JSON Schema），或者结合框架提供的 Structured Outputs，以便后端代码可靠解析。
  • 少样本示例 (Few-Shot)：
    • 对于意图分类、槽位提取等高频任务，给 2~3 个正反例，稳定性远胜于写上千字的规则说明。
  • 防御性指令与 XML 隔离：
    • 利用 XML 标签（如 <user_input>、<rag_context>）包裹和隔离不可信输入，防止 Prompt Injection（提示词注入） 覆盖系统原本的设定。
  • Prompt Chaining (提示词链式拆分)：
    • 将复杂任务拆解，每步使用独立的 Prompt（第一步只做意图识别，第二步只做参数提取，第三步做工具装配）。不仅提升准确率，更让每个节点可独立调试与评估。

2. 如何做好上下文工程 (Context Engineering) ​

上下文工程是 LLM 窗口的“内存管理”，其核心是在有限的 Token 预算内，构建高信噪比的信息工作台：

  • 分层渐进式披露 (Progressive Disclosure)：
    • 不要把全量工具 Schema 和历史对话一股脑塞给模型。
    • 步骤：根据意图识别结果，动态挂载工具白名单；根据用户当前诉求，只检索召回与该意图直接相关的 RAG 证据。
  • 上下文排序与 Lost in the Middle 治理：
    • 模型对上下文首尾的信息敏感度极高，中间部分最容易被忽略（Dumb Zone / Lost in the Middle）。
    • 策略：将“核心系统规则、安全边界、输出格式”置于最前（或最后），将“用户实时输入”置于尾部，对 RAG 证据进行重排（Rerank），将高置信度证据排在最前。
  • 历史对话压缩与重置 (Context Reset)：
    • 拒绝无脑拼接聊天记录。在长对话中，使用大模型在后台异步生成“历史摘要（Summary）”，窗口中仅保留 [全局摘要] + [最近 N 轮对话文本]。
  • 工具 Observation 数据净化：
    • 大模型不需要看后端返回的完整 JSON 报文（可能包含大量没用的审计字段或 null 值）。
    • 策略：在 Harness 的工具执行器中过滤响应，只保留大模型决策所需的关键字段（如 status、reason、success）回填给上下文。

3. 如何做好 Harness 工程 (Harness Engineering) ​

做好 Harness 工程必须采用分层设计思维。我们可以将 Harness 拆解为六层架构，在每一层中明确其职责及“防范线上故障”的兜底机制：

mermaid
graph TD

    A[信息边界层: 角色、目标、状态裁剪] --> B[工具系统层: MCP、白名单、参数清洗]

    B --> C[执行编排层: Advisor链、控制循环]

    C --> D[记忆与状态层: Redis状态、任务持久化]

    D --> E[评估与观测层: 日志Trace、混沌测试]

    E --> F[约束与恢复层: 二次确认、熔断限流、后端校验]

🛡️ Harness 六层架构及防范线上故障手册： ​

  1. 信息边界层
    • 解决什么：控制 Agent 的认知范围，防止角色漂移和上下文污染。
    • 没设计好导致的线上故障：越权回答（如客服回答了竞争对手的产品问题，或透露了敏感内部系统接口）。
  2. 工具系统层
    • 解决什么：模型如何与外界安全交互。
    • 没设计好导致的线上故障：工具越权调用（比如模型直接调用了 deleteUser 接口），或者模型由于参数缺失反复重复调用同一个接口，导致 Token 账单爆炸和 API 限流崩溃。
  3. 执行编排层
    • 解决什么：编排 Agent 推进任务的轨道，限制其思考和执行步骤。
    • 没设计好导致的线上故障：跳步（未查订单先退款）、漏步（忘发送确认邮件）或陷入死循环。
  4. 记忆与状态层
    • 解决什么：管理 Agent 执行中产生的短期状态、变量和中间产物。
    • 没设计好导致的线上故障：在长任务执行到一半网络抖动中断后，系统无法恢复；或者带着上一轮被污染的“脏状态”继续跑，导致后面所有决策连环出错。
  5. 评估与观测层
    • 解决什么：通过实时监测和自动化评测，知道 Agent 在线上做得对不对。
    • 没设计好导致的线上故障：线上发生严重的幻觉导致用户资损，系统没有任何告警，故障完全依赖用户投诉才被发现。
  6. 约束与恢复层
    • 解决什么：出错了怎么限损，高风险操作怎么围堵。
    • 没设计好导致的线上故障：网络超时后系统盲目重试，导致退款动作被重复提交（无幂等控制）；或者发生连环调用失败时，整个系统卡死或输出乱码，无法优雅退回人工客服。