2026年10月6日一、今天学了什么今天的学习主线其实可以归结成一个问题当一个大模型应用效果不好时到底应该怪模型、上下文、运行系统还是整个执行流程今天真正把系统拆开以后需要区分四个层次Prompt → 模型应该遵守什么规则 Context → 这一次模型能够看到什么信息 Harness → 模型之外系统如何提供能力并控制执行 Loop → 一次执行之后系统如何继续行动、反馈或终止另一条学习线是 RAG EvaluationRAG 评估。以前容易直接看“最终答案对不对”但这无法回答一个更重要的问题错到底错在 Retrieval还是 Generation所以今天真正建立起来的是一种“分层定位问题”的系统思维。二、Prompt、Context、Harness、Loop 到底分别解决什么问题这是今天最值得长期保留的一组概念。1. Prompt解决“模型应该按什么规则工作”Prompt 本质上是给 LLM 的指令Instruction。例如你是企业知识库助手。 只能根据提供的资料回答。 如果资料不足明确说明不知道。它主要解决角色是什么 任务是什么 应该遵循什么输出规则 什么事情应该做 什么事情不应该做所以可以记成Prompt 管规则和指令。但这里必须纠正一个非常重要的理解Prompt 里的“禁止”不等于真正的系统权限控制例如禁止删除用户文件。即使把这句话写进 System Prompt也不能把它当成真正的安全边界。因为 LLM 本质上仍然是概率模型。真正的权限控制应该存在于程序层if tool_name delete_file and not user.has_permission: raise PermissionError(permission denied)也就是说Prompt Constraint ↓ 告诉模型应该怎么做 Program Constraint ↓ 决定系统实际上允许做什么Prompt 是软约束soft constraint程序权限通常才是硬约束hard constraint。三、Context 不只是聊天记录而是“这一轮模型真正能看到的信息”我之前很容易把 Context 理解成对话历史。这个理解太窄。Context上下文更准确的理解应该是当前这一次 LLM 调用时被放进模型输入中的全部有效信息。例如一次 Agent 调用可能包含System Prompt 用户问题 最近几轮 Messages RAG 检索结果 Tool Observation 当前 Plan 部分 Memory 任务状态摘要这些东西共同构成当前模型看到的 Context。因此Context 管“这一刻给模型看什么”。这里还有一个非常容易混淆的概念State ≠ Context假设一个 Agent State 中保存state { messages: [...], plan: [...], retrieved_docs: [...], tool_outputs: [...], retry_count: 2, user_profile: {...}}并不意味着每次调用 LLM 都要把这些内容全部塞进去。State 是系统当前保存的完整任务状态。Context 是当前这一次模型调用从 State 和其他信息中挑选出来的输入视图。因此更合理的关系是State ↓ Context Engineering ↓ Selected Context ↓ LLM这也是为什么Context Engineering上下文工程不等于简单拼 Prompt。它还涉及哪些信息应该进入模型哪些信息应该压缩哪些应该被丢弃Tool Result 怎么表示Memory 什么时候注入RAG 文档放多少。四、Harness模型之外谁负责把 Agent 真正运行起来今天我对 Harness 的理解也清晰了很多。如果把 LLM 比作“做决策的大脑”那么 Harness 更像围绕模型搭建的运行环境、能力组织方式和控制系统。它负责的不是单纯“让模型生成文字”而是让模型真的能够调用工具 访问状态 执行动作 处理失败 限制权限 控制超时 组织下一轮调用所以 Harness 通常会涉及LLM │ ├── Prompt / Context Builder ├── Tool Registry ├── Tool Executor ├── State ├── Validation ├── Timeout / Retry ├── Permission └── Runtime Control这里要注意Agent 整体可以包含 Harness但 Harness 不是 LLM 本身。它更接近“让 Agent 可以可靠运行起来的工程外壳”。Prompt 决定模型怎么想Context 决定模型看到什么Harness 决定模型有什么能力以及这些能力如何被安全执行。五、Loop不是 Retry而是 Agent 持续行动的基本机制我之前容易把 Loop 理解成工具失败以后再试一次。这其实把 Loop 和 Retry 混在了一起。Retry 只是 Loop 中可能出现的一种行为。真正的 Agent Loop 更接近LLM Decision ↓ Action ↓ Tool Execution ↓ Observation ↓ Update State ↓ LLM Decision ↓ ...也就是说Loop 解决的问题是一次行动完成之后系统根据结果决定下一步做什么。一次完整循环至少可能包含观察结果 ↓ 更新状态 ↓ 判断任务是否完成 ↓ 如果没完成决定下一步 ↓ 再次调用工具或模型因此Loop 管多步行动和反馈。而且生产系统中的 Loop 一定不能无限运行还必须存在 Hard Stop硬终止条件例如maximum_steps maximum_retries timeout token_budget cost_budget explicit_finish fatal_error否则所谓的 Agent autonomy自主性很容易变成失控的无限循环。六、四层之间不是完全平级而是存在包含关系今天还有一个细节很重要。这四个概念为了学习方便可以并列讲但它们并不是四个完全独立的盒子。例如Prompt 通常属于 Context 的一部分模型最终看到的输入可能是Context ├── System Prompt ├── User Message ├── Retrieved Docs └── Tool Observation因此可以理解为Prompt ⊂ Context至少从一次模型调用的输入视角看这种理解是成立的。而 Loop 通常也不会脱离 Harness 独立存在。例如 Harness 中的 Runtime 可能负责for step in range(max_steps): action llm(context) if action.finished: return action.answer observation execute(action) state.update(observation)这里真正执行代码的是 Agent Loop。Decision → Action → Observation → Next Decision因此可以粗略理解为Agent Harness │ ├── Context Construction │ └── Prompt │ ├── Tool Runtime │ ├── State Management │ └── Agent Loop这比简单背四个定义更接近真实系统。七、RAG 评估为什么不能只看最终答案今天第二个重要认知是 RAG Evaluation。假设用户问公司的年假是多少天RAG 系统回答错了。如果只看到Answer Accuracy Wrong其实什么也定位不了。可能发生至少两种完全不同的问题。情况一Retrieval 错了用户需要员工休假制度.pdf但是系统检索出来的是员工考勤制度.pdf 公司福利介绍.pdf这时生成模型再强也缺少正确证据。问题属于Retrieval Failure情况二Retrieval 对了但 Generation 错了系统已经成功检索正式员工每年享有 10 天带薪年假。模型却回答员工每年享有 15 天年假。这时 Retriever 没有问题。真正的问题属于Generation / Grounding Failure因此 RAG 必须分层评估。八、RAG 最值得关注的四类指标今天重点梳理的是下面几个指标。1. Context Recall回答应该检索到的信息找全了吗例如正确答案需要 A、B、C 三块证据但只找到了 A 和 B那么 Recall 就存在问题。它更偏向Retrieval Coverage2. Context Precision回答检索出来的内容里面有多少是真正有用的如果 Top-5 中Doc1 ✓ Doc2 ✗ Doc3 ✗ Doc4 ✓ Doc5 ✗虽然可能找到了答案但噪声很大。这说明 Precision 较差。因此Recall → 有没有漏掉正确内容 Precision → 找出来的内容是不是太脏3. FaithfulnessFaithfulness忠实度解决最终回答中的结论是否真的被检索 Context 支持这是 RAG 非常关键的生成侧指标。例如 Context 写年假为 10 天模型回答年假为 15 天这就是明显的 Faithfulness 问题。所以它关注的不是“语言通不通顺”而是Answer Claim ↓ 是否能被 Context 支持4. Response RelevancyResponse Relevancy 关注最终回答有没有真正回答用户的问题。例如用户问年假多少天模型输出一大段公司的休假制度分为年假、病假、婚假……即使内容都真实也可能没有直接回答核心问题。所以Faithfulness → 有没有依据 Response Relevancy → 有没有答到点上这两个指标不能混为一谈。九、今天形成的 RAG Debug 思路以后再遇到一个 RAG Bad Case我不能上来就说换 Embedding、换 Reranker、改 Prompt。更合理的第一步应该是定位故障层User Query ↓ Retrieval ↓ Retrieved Context ↓ Generation ↓ Final Answer然后依次判断正确文档有没有被召回 ↓ Context Recall 召回结果噪声是不是很多 ↓ Context Precision 正确证据已经给模型了吗 ↓ 如果给了仍然胡说 ↓ Faithfulness 答案有依据但没回答问题 ↓ Response Relevancy这比直接“调参数”重要得多。至于完整的RAG Bad Case 优化策略今天的学习内容还没有完成系统验证所以这里暂时不把 Query Rewrite、Hybrid Retrieval、Reranker 等方案写成已经验证有效的结论。这一部分更适合后续单独做一次完整的Bad Case → Failure Classification → Optimization → Offline Evaluation → Regression Test再进行总结。十、今天最重要的两个认知修正我原来以为Agent 的核心就是 Prompt 写好再让模型调用几个 Tool。实际上真正的生产 Agent 至少需要同时考虑 Prompt、Context、Harness 和 Loop。模型只是决策组件系统能力、控制边界、状态和循环机制同样决定最终成功率。我原来以为RAG 效果不好就是看最终答案对不对然后继续优化检索。实际上必须把 Retrieval 和 Generation 分开评估。否则一个生成阶段的 Faithfulness 问题很可能被错误地归因到 Embedding 或 Retriever。十一、今天留下的问题Agent 的 State 很大时Context Builder 应该根据什么规则决定哪些状态进入当前 Context如果 RAG 的 Context Recall 很高、Faithfulness 仍然很低应该优先改 Prompt、模型还是 Context 组织方式Harness 和 Runtime 在真实 Agent 工程里应该如何划分边界Runtime 是 Harness 的一部分还是应该被建模成独立层今天真正建立起来的一套思维是不要把所有问题都归因于 LLM。Prompt 管规则Context 管信息Harness 管能力与控制Loop 管持续行动而 RAG 也必须把 Retrieval 与 Generation 拆开评估。只有先定位问题属于哪一层优化才有意义。