AI转型之路
2026-09-14 15:06:20 0 举报这不是普通的 Agent 资料整理，而是在逐渐形成一套“生产级 Agent 系统方法论”。内容深度已经很高，结构也基本成型。Model → Context → Tools → Loop → Harness → Memory/RAG → Security → Evaluation → Multi-Agent
AI
模板推荐
作者其他创作
大纲/内容
agent基础概念
Agent 最简洁的公式
Agent= LLM+上下文+工具
抽象层次结构图片
最小交互结构
LLM
策略Policy
Agent 决定“下一步做什么”的决策逻辑
上下文构造
观察与历史
将环境返回的观察与已有历史组织成当前决策所需的信息
工具与适配
观察/行动接口
规定 Agent 可以读取哪些观察、发出哪些行动，以及接口采用什么格式
观察空间与动作空间-模型与世界的接口
观察通道与动作接口共同构成了 Agent 与外部环境之间的边界
在底层模型固定时，提升 Agent 任务表现最主要的系统工程手段，往往就是重新定义或扩展观察空间与动作空间
产品领域
Cursor 等 Coding Agent
眼睛（感知）
需求、读取到的代码片段、目录列表、终端输出
手脚（行动）
开放式（代码搜索、文件读写、执行命令等）
策略
增量开发
理解需求
搜索相关代码
编辑代码
测试验证
调试修复
Deep Research 等搜索 Agent
眼睛（感知）
搜索结果、网页内容、论文摘要与引用
手脚（行动）
开放式（搜索查询、网页读取、生成报告等）
策略
迭代深化：根据已有信息调整搜索方向，逐步综合出完整报告
Browser Use 等电脑操控 Agent
眼睛（感知）
屏幕截图、DOM 或无障碍树、操作结果
手脚（行动）
开放式（点击、输入、滚动、截图、执行代码等）
策略
视觉感知+操作
观察屏幕
识别目标元素
执行操作
验证结果
豆包等手机助手 Agent
眼睛（感知）
手机截图、App 界面状态、系统反馈
开放式（点击、滑动、输入、打开 App 等）
手脚（行动）
开放式（点击、滑动、输入、打开 App 等）
策略
意图理解+App 操控
理解用户需求
定位目标 App
执行操作
确认完成
Pine AI 等个人办事 Agent
眼睛（感知）
经授权读取的账户记录、账单结果、服务商资料
手脚（行动）
开放式（打电话、发邮件、填表单、与用户确认）
策略
多步骤任务执行
收集信息
制定协商策略
联系服务商
谈判
汇报结果
工具：Agent 的手脚<br>
工具定义
工具是 Agent 与外部世界交互的桥梁：感知类工具承载环境到 Agent 的观察，执行类工具承载 Agent 到环境的行动
Agent 与外界互动方向的五类工具
感知工具
让 Agent 能访问信息
搜索引擎提供实时网络数据，文件系统读取本地文档，API 和数据库则对接外部服务和企业核心数据
执行工具
让 Agent 改变世界
代码执行、文件操作、系统命令、外部 API 调用——决策由此变成实际行动
协作工具
让 Agent 与其他 Agent 分工合作
委托子 Agent 完成专项任务，在关键决策点请求人类确认，或在多 Agent 系统中协调行动
事件触发工具
外部输入来驱动 Agent 开始执行任务
事件适配器同样是 Environment 向 Agent 提供观察的通道，因此本书把它归入广义的工具体系
用户沟通工具
Agent 主动与用户建立连接、传递信息的渠道
用户沟通工具专注于信息的传递和交互
通过文字消息、语音通话、邮件等方式，将 Agent 的执行进展或主动关怀传达给用户
工具调用 Tool_Calling Function_Calling
它让模型能够通过结构化的方式调用外部工具
这种能力将 LLM 从一个纯粹的文本生成器转变为能够执行实际操作的智能系统
工具调用的流程分为四步
声明工具
模型决定调用
结果追加到上下文
模型基于结果回复
工具设计的核心原则
通用基础能力用于组合与探索；专用工具用于约束高风险和强业务规则操作
LLM Large Language Model 大语言模型 Agent 的决策核心
模型即 Agent：当模型本身成为产品
先进模型通过后训练（特别是强化学习）将工具调用能力内化为原生能力
Harness 这个词原指马具，即套在马身上的缰绳与挽具，不是为了限制马的奔跑能力，而是把这种力量引导到正确的方向上
模型是那匹强大但不可预测的马，Harness 则是把它的能力引导成可靠任务执行的工程外壳
Harness 包括上下文管理、工具接口、安全约束、验证与纠正等基础设施
Agent 的学习机制：从上下文适应到持久更新
<br>
上下文适应发生在当前任务中
要让变化跨越任务保留下来，可以更新外部产物：把事实和经验整理为知识文档，把可语言化的策略写进 Prompt 或 Skill，把确定性流程与约束写成程序和 Harness
外部规则难以完整表达，就需要通过后训练更新模型参数,参数更新的部署成本较高，却能形成自然、广泛的泛化能力
上下文：Agent 的眼睛
上下文是 Agent 在每个决策点能看到的全部信息
每次调用 LLM 时的上下文由以下五个部分构成
系统提示词（System Prompt）
定义它的身份、权限和行为准则
系统提示词中还会包含跨会话保存的用户记忆（用户偏好、历史行为、背景设定等个性化信息，详见第三章）和动态注入的环境状态
工具定义（Tool Definitions）
声明 Agent 可用工具的名称、功能描述和参数格式
工具定义与系统提示词一起构成对话中保持不变的静态前缀
用户消息（User Messages）
来自用户的输入
用户消息中还可能包含通过 RAG,动态检索引入的外部知识覆盖训练数据截止后的信息或私有领域知识
模型回复（Assistant Messages）
模型之前生成的回复，最多包含三个部分
思考过程 reasoning
内部思考链，用于保持思维的连贯性和决策的可解释性
文本内容 content
对用户的回复
工具调用请求
Agent 采取行动的方式
工具执行结果（Tool Results）
Agent 框架执行工具后返回的结果
(系统提示词 + 工具定义）是静态前缀 +（用户消息 + 模型回复 + 工具执行结果）是随交互不断增长的动态消息历史 =共同构成了 LLM 每次推理时的上下文
消融实验（Ablation Study）
验证每个组件是否都不可或缺
ReAct 循环
Agent 执行任务的核心模式叫做 ReAct（Reasoning + Acting） 先思考 然后调用工具行动，再观察工具返回的结果并继续思考下一步
轨迹
轨迹是 Agent 在执行任务过程中不断积累的消息历史——用户消息、模型回复（包括思考过程和工具调用）、工具执行结果
每一次调用 LLM 时，它接收的完整上下文由静态前缀（系统提示词 + 工具定义）和轨迹（动态消息历史）两部分组成
Agent 的上下文 = 静态前缀 + 轨迹
轨迹的结构化也让系统易于解释和调试——用户消息、模型回复（思考过程 + 工具调用）和工具执行结果彼此分明
分析大量轨迹可以发现 Agent 的行为模式、优化决策路径、改进工具设计
轨迹还可以沉淀进知识库，或用于强化学习训练更好的模型，形成从经验中学习的闭环
市场工具
Harness 工程：模型之外的竞争力
用方程展开生产形态下的完整组成
Agent = Model + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正
Agent <-> Environment
Agent 边界内、模型之外的运行与治理层
Harness 的核心是上下文管理与工具接口
它负责协调 Model 与 Environment 的交互，但不包括与之交互的环境本身：工具定义、调用适配器、沙箱的权限与重置机制属于 Harness
沙箱内随行动变化的文件和进程、外部数据库、网页、用户及物理世界属于 Environment
物理部署位置也不能决定概念归属——即使仿真环境与 Agent 运行在同一进程中，它仍然是 Environment
三类工程化保障机
Context（上下文）
为模型提供感知信息；信息要充分，让 Agent 在每个决策点都基于足够的信息判断
系统提示词、知识库、Agent 状态栏、Sidecar 旁路查询
Tools（工具接口）
为模型提供观察与行动手段；接口要清晰，命名直观、参数有例子、边界有说明
MCP 工具、代码解释器、搜索工具
Constrain（约束）
设定行为边界；采用故障安全默认值，所有能力默认关闭，必须显式开放（类似手机 App 权限管理）
Claude Code 中每个工具默认需要用户授权才能执行
Verify（验证）
自动判断操作结果的对错；安全检查只看结构化数据（如工具返回的 JSON 字段），而不看模型自由生成的文本，因为后者可能已被提示注入操纵
Linter 检查、类型系统、工具调用结果校验
Correct（纠正）
发现问题时自动修正或回退；在确认无法恢复之前不暴露中间态，例如工具调用失败时先静默重试，不把半成品结果展示给用户
静默重试、接续生成、连续失败时回退到人工判断（熔断机制）
五个功能构成一个闭环
上下文与工具让 Agent “能做事”——理解任务并采取行动
约束预防错误，验证发现偏差，纠正使闭环得以形成，三者共同让 Agent “不做错事”
生产级 Agent 系统的重心已经转向约束、验证与纠正：确保工具调用是安全的、上下文是经过管理的、错误是可恢复的
Claude Code 为例
围绕这些工具构建的保障机制才是真正的核心
流程状态管理：追踪 Agent 当前执行到哪一步
多层上下文压缩：当信息太多时自动精简
权限分类：控制哪些操作需要用户确认
熔断器（Circuit Breaker）：当错误连续发生时自动“断电”停止重试——就像家里电路短路时保险丝会自动跳闸，防止整个系统崩溃
错误恢复机制：捕获异常、回滚到上一稳定状态、重试或交还给人类<br>
行业正在从“能做事”向“可靠地做事”转变，Harness 工程因此成为 Agent 系统的核心竞争力。<br><br>
从提示工程到 Loop 工程：工程范式的演进
AI 应用工程的发展
提示工程（Prompt Engineering）
通过优化输入给模型的自然语言指令来提升输出质量
上下文工程（Context Engineering）
系统性地管理模型能看到的所有信息（系统指令、工具定义、对话历史、外部知识）
Harness 工程
涵盖上下文与工具接口、约束机制、验证手段、反馈循环和错误恢复等 Agent 边界内、模型之外的运行与治理机制
Loop 工程（Loop Engineering）
把视野从单次运行扩展到跨轮次的持续自主运转
Graph 工程（Graph Engineering）
把 Agent 循环、确定性程序和人工审批组织成显式的执行图，其中节点承担具体能力，边规定路由与依赖，结构化状态沿边传递并在关键边界处持久化
构建有效 Agent 的核心原则
保持简单
从最简单的方案开始，只在确实必要时才增加复杂度
保持透明
明确显示 Agent 的规划步骤、执行日志和决策轨迹——这不只是为了调试方便，也是让用户建立信任的前提
设计好工具接口
ACI 强调的是从 Agent 视角设计接口（让 Agent 容易理解和使用），而非传统 API 从程序员视角设计接口
工具的命名和参数要直观，容易误用的地方要从设计上让错误无法发生
因为模型与工具之间唯一的沟通通道就是接口本身，模糊的接口会被模型放大成系统性的错误
编排模式：工作流与自主
护栏与安全性
护栏与安全性
应用于反思
Harness 中“上下文与工具”层面的组织方式——它决定了上下文如何在 LLM 调用之间流动、工具如何被调度，以及 Agent 的执行路径是预先设定还是动态生成
在构建 LLM 应用时，应遵循“从简单到复杂”的原则：首先考虑单个 LLM 调用。如果通过优化提示词和上下文示例就能解决问题，就不要引入 Agent 系统
当需要多步骤处理时，对于可以清晰分解为固定子任务的场景，考虑使用工作流
只有当需要动态决策和灵活的执行路径时，才使用自主 Agent
Agent 系统通常会用延迟和成本换取更好的任务性能，应该谨慎权衡这种交换是否值得
先给一个能力足够的 Agent 清晰的目标、必要的上下文和可组合的工具，用自然语言告诉它如何像人一样查证、比较、处理冲突
程序只固化权限、不得覆盖原始材料、原子发布等必须始终成立的边界
只有业务约束本身要求，或评估反复暴露出某类稳定失败时，才把对应步骤升级为专门的验证器、独立 Agent 或确定性流程
好的结构不是替 Agent 预演全部思考，而是守住边界，并把边界内的决策空间还给模型
工作流模式：确定性的编排
工作流（Workflow）
是通过预定义的代码路径来编排 LLM 和工具的系统
执行路径是确定性的，由开发者预先设计
LLM 只在每个节点内部负责理解和生成
工作流模式有两个核心优势
严格的流程控制
开发者可以确保关键步骤不被跳过或乱序执行
安全性
由于执行路径是确定的，提示注入或模型犯错最多只能影响当前节点内部的处理，无法让 Agent 跳到不该执行的分支
主要局限
缺乏变通性
自主 Agent：动态自主决策
自主 Agent（Autonomous Agent）
执行路径不是预先定义的，而是 Agent 根据环境反馈实时决定的
自主 Agent 需要具备自主规划的能力
自主决定执行步骤，还需要能识别失败、调整策略，而不只是在出错时停下来
设计明确的停止条件（任务完成、达到最大迭代次数或遭遇不可恢复的错误）
<br>
两种模式的选择与混合
关键的、有严格合规要求的流程用工作流来确保可靠性，需要灵活决策的部分切换到自主模式
先由自主 Agent 把工作流写出来，再由工作流去执行
主流的 Agent 框架/平台
Codex Harness Codex 安全带
核心定位
Codex 的开源 Agent 运行时 L'environnement d'exécution open source de l'agent Codex
编排模式
自主
开发方式
代码优先，可嵌入自有应用
适用场景
Coding Agent、把 Agent 嵌进自家产品<br>Coding Agent, integrating the Agent into its own products
Claude Agent SDK
核心定位
生产级 Agent 开发框架
编排模式
自主
开发方式
代码优先
适用场景
复杂自主任务、Coding Agent Complex autonomous tasks, Coding Agent
LangChain / LangGraph
核心定位
通用 LLM 应用框架
编排模式
工作流 + 自主
开发方式
代码优先
适用场景
复杂链式思考、多步骤工作流
n8n
核心定位
可视化工作流自动化
编排模式
工作流 + 自主
开发方式
低代码（可视化拖拽）
适用场景
业务自动化、非技术团队
Dify
核心定位
LLM 应用开发平台
编排模式
工作流 + 对话式
开发方式
低代码（可视化 + API）
适用场景
企业级 RAG、知识库应用
CrewAI
核心定位
角色化多 Agent 编排
编排模式
Multi-Agent 协作
开发方式
代码优先
适用场景
团队式任务分解与执行
OpenClaw
核心定位
开源全能个人 Agent
编排模式
自主 + 事件驱动
开发方式
配置 + 代码（自托管）
适用场景
个人助理、Deep Research、Computer Use、多平台消息集成
个人助理、深度研究、计算机使用、多平台消息集成
DeepSeek Harness DeepSeek 装置
核心定位
Agent 自进化框架
编排模式
一切皆插件
开发方式
代码优先，方便定制
适用场景
Agent 开发者、研究者
Pi
核心定位
极简 Coding Agent 框架 Minimalist Coding Agent Framework
编排模式
自主
开发方式
代码优先，方便定制
适用场景
Agent 开发者
护栏与安全性
护栏（Guardrails）
构成了保障 Agent 行为安全可控的分层防线，可用于管理数据隐私风险或声誉风险
误拒绝
为了降低危险请求被放行的概率，模型可能同时拒绝一部分合法但形式敏感的任务
护栏类型
上下文层
护栏管的是模型输入窗口
相关性分类器
安全分类器
检测越狱
用户自己试图绕过模型的安全限制
提示注入
提示注入则是攻击者通过外部数据间接操纵模型行为
内容审核
标记有害或不当的输入，如暴力、歧视性内容
基于规则的保护
采用确定性措施，包括黑名单、输入长度限制、正则表达式过滤器，用以防范 SQL 注入等已知威胁
代表性工业实践
规则驱动
用自然语言写成的规则,生成合成训练数据，训练输入输出分类器
上下文联合判断
把用户提问和模型回答放在一起检查
两级筛查
先用一个极轻量的探针检查所有对话
发现可疑之处再交给更强的分类器复审
处在同一个上下文里的 Agent，很难判断自己是否已经被注入
执行层
护栏管的是模型的决策执行
核心是工具风险评级
根据操作为每个工具标注风险等级（低/中/高），高风险操作需额外审查或人工确认
是否可逆
权限等级
财务影响
复核由上下文之外的机制完成
独立的审查进程
最小权限凭证
沙盒隔离
人在回路
输出检查
PII 过滤器
审查输出中的个人身份信息
输出验证则通过内容检查确保回复与品牌价值一致
数据层
数据执行内容
给一层稳定的、经过人类审查的机制强制执行
数据库的行级安全策略
约束与校验器
受控视图
存储过程
由受信任运行时绑定、无法被伪造的访问上下文
人工干预 Human in the loop，又称人在回路
实施人工干预机制，可以让 Agent 在无法完成任务时平稳地移交控制权
触发人工干预
超过失败阈值
为 Agent 的重试次数或操作次数设置上限
高风险操作
涉及敏感、不可逆或高风险的操作时，应触发人工监督
Harness 要素
上下文管理
提示工程、Agent 状态栏、上下文压缩、Agent Skills
提示注入、上下文污染
上下文管理（跨会话）
用户记忆、RAG、结构化索引、智能体化 RAG
敏感信息暴露、隐私保护
工具接口与约束
工具分类、权限控制、MCP 标准、主动工具发现
误操作、未授权访问、不可逆操作
验证与纠正
Coding Agent 的 Harness、测试驱动、代码化规则
身份冒用、责任归属
贯穿全书的设计模式
提议者—审核者（Proposer-Reviewer）
渐进式披露（Progressive Disclosure）
只增不改（Append-only）
边界集 + 保留集（Boundary Set + Retention Set）
最小 diff + 可回滚
上下文工程 Context Engineering
上下文：决定 Agent 能力上限的关键
上下文工程因此成为利用现有模型开发高效 Agent 的关键所在
系统性地设计、组织和提供 AI 完成任务所需的全部背景知识
这不只是技术问题，更是组织问题
对远程工作友好的团队往往也对 AI Agent 友好
信息是公开的、可检索的、结构化的
Agent 的下一步行动取决于截至当前的完整交互上下文，而不只是眼前这一条输入
对 LLM Agent 来说
用户消息和工具执行结果是环境返回的观察
模型回复和工具调用请求是 Agent 已经采取的行动
这些观察与行动交替累积，就形成了交互历史
真实 API 请求还会在这段历史之前放入系统提示词和工具定义，共同组成模型本轮实际收到的上下文
由于模型 API 本身是无状态的，每次调用时都必须由 Agent 框架重新构造足够的上下文
最直接、无损的做法是带上此前的完整消息历史
生产系统也可以做摘要和压缩，但不能悄悄丢掉决定下一步行动所需的信息
Agent 如何调用大模型：理解 API 的上下文结构<br>
大模型API核心结构
消息列表（messages）+角色（role）标识
system 系统提示词
Agent 的身份
行为规则
约束条件
最高优先级的指令
user 用户消息
来自终端的用户输入
assistant 助手消息
模型历史回复
文本回复
工具调用请求
tool 工具结果
Agent 框架执行工具后，将结果以 tool 角色的消息送回给模型
每条 tool 消息通过 tool_call_id 与对应的工具调用请求关联
工具定义（tools）作为请求的独立字段（而非消息）
报文结构
{<br> "model": "Qwen3-0.6B",<br> "messages": [<br> {<br> "role": "system", // ← Written by developer<br> "content": "You are a helpful coding assistant. Follow user instructions."<br> },<br> {<br> "role": "user", // ← User input<br> "content": "Hello, who are you?"<br> }<br> ]<br>}<br><br>
每次调用都是无状态的，所有模型需要的信息必须在请求的消息列表中完整提供
带工具调用的多轮交互：Agent 的核心循环
模型只是发出了调用请求，真正执行工具的是 Agent 框架
Agent 框架执行工具 可以并行执行 然后完整的对话历史加上工具执行结果
请求→工具调用→执行→送回结果→再请求
ReAct 循环在 API 层面的具体实现
用代码实现 Agent 的核心循环
核心逻辑只有一个 while 循环和一个判断
模型返回了 tool_calls 就执行工具并继续循环，没有就输出结果并退出
整个过程中，messages 列表不断增长——每一轮都会追加模型的回复和工具的执行结果
Agent 框架的核心工作就是管理这个 messages 列表——在合适的时机往里追加消息，然后把整个列表送给模型
从 API 视角看上下文的构成
每次调用模型时,上下文的完整构成
上半部分（System Prompt + Tool Definitions）在整个对话过程中保持不变
下半部分（对话历史，即第一章所定义的轨迹）随着交互的进行不断增长
系统提示词和工具定义构成静态前缀，用户消息、模型回复和工具执行结果构成动态增长的消息历史
KV Cache 友好的上下文设计
KV Cache
复用的上下文 token 前缀保持不变
把前文的中间计算结果缓存下来，下一轮只需要计算新增 token 的部分
缓存命中 Prompt Cache
注意力机制可视化
Query（查询）
当前词发出的“搜索请求”
Key（键）
每个词的“标签”，用于被搜索匹配
Value（值）
每个词的“内容”，匹配成功后被提取
计算过程分三步
生成自己的 Query 向量
Query 与每个词的 Key 做点积
匹配度打分
两组数字逐位相乘再加起来，结果越大说明越匹配
得到注意力权重
权重对所有词的 Value 加权求和——打分高的词贡献多，打分低的词贡献少
注意力热力图
把每个词对前面所有词的注意力权重排成一个矩阵
热力图呈三角形——因为模型是从左到右逐个生成的，每个词只能看到自己和前面的词
KV Cache 原理
KV Cache 就是把已算过的 K 和 V 缓存起来，让新词直接复用
注意力储存池
序列的第一个 token 往往吸收了异常高的注意力权重，有时超过总注意力的 70%。
模型将这个位置用作“注意力储存池”（Attention Sink），存放那些不需要分配到其他具体 token 上的多余注意力权重
思考的三角形模式
模型思维链（<think> 标签内）展现出三角形状的自注意力模式——生成新的思考内容时频繁“回看”之前的思考内容和工具定义
输出的三角形模式
思考结束后的输出过程展现出另一个三角形，模型用思考过程作为提示来输出回答
位置偏好（Position Bias）
模型对上下文开头和结尾的信息分配了更高的注意力，中间部分则更容易被忽视
从 API 消息到模型 Token：Chat Template
API 层面的结构化消息需要被转换为模型能理解的线性 token 流——负责这个转换的就是 Chat Template（聊天模板）
用特殊标记（如 <|im_start|>system、<|im_end|>）划分每条消息的边界和角色
API 服务端（vLLM、Ollama 等）会根据模型的 Chat Template 自动完成这个转换，开发者通常不需要手动处理
存在对 Agent 开发有两个实用价值
开发者绕过 API、自行拼接消息,Chat Template 会误将工具响应识别为新的用户查询，导致模型的思维链保留机制被破坏
Chat Template 将 system 消息和工具定义转换为固定的 token 序列放在最前面,oken 的键值对（Key-Value pairs）被缓存后可以跨请求复用,但如果前缀中某个 token 发生变化,首个不同 token 及其后的缓存就无法复用
KV Cache 的原理与约束
无缓存时，prefill 阶段（即模型生成回复之前，处理输入的全部 token 的阶段）的注意力计算量随上下文长度平方级增长，随着对话深入，延迟和成本都会急剧攀升
大语言模型由多层 Transformer 堆叠而成,每一层都独立生成自己的 K、V 缓存,这些层是串联的,层层向下传递，就像流水线上的工序,在处理每个词时，会综合考虑该词及其前面所有词的信息，然后输出一个中间结果
实际复用时，缓存只能保留到首个不同 token 之前，从该位置起需要重新计算
代价取决于改动位置：变动点越靠前，需要重新计算和计费的 token 越多，延迟影响通常也越大
常见的错误上下文管理模式
动态系统提示词
动态用户配置
工具定义的动态排序
滑动窗口（Sliding Window）对话历史
文本格式化方法
型提供商为标准接口做了大量的优化，偏离标准格式往往是在给自己挖坑
KV Cache 与 Prompt Cache：两个层级的缓存
区分概念
KV Cache 是模型内部的机制
KV Cache 加速单次请求内的 token 生成
Prompt Cache 则是推理引擎的优化
Prompt Cache 减少跨请求的重复计算成本
API 服务商对请求的前缀进行匹配，如果多次请求的前缀相同，就直接复用之前计算好的 KV Cache，而不需要重新计算这部分 token 的键值对;缓存读取的成本远低于首次计算
缓存作为架构约束
定义
生产级的 Agent 系统中，缓存不仅仅是性能优化手段——它是一个架构约束，决定了系统中许多看似无关的设计决策
体现这种约束的设计决策
提示词的结构由缓存边界决定
系统提示词在物理上被一个缓存边界标记分为两部分
标记之前的内容可以跨用户,跨会话进行全局缓存
标记之后的内容则包含用户和会话的特定信息
提示词的排列顺序首先由缓存的经济性决定，其次才是语义逻辑
每个运行时条件（操作系统类型、当前模式、用户偏好等）如果被放在缓存边界之前，就会把缓存键的变体数量翻一倍
因此所有的动态元素都需要放到边界之后
子 Agent 必须与父 Agent 字节级对齐
当主 Agent 派生子 Agent 或进行旁路查询时,如果子 Agent 继承父 Agent 的上下文,子 Agent 的提示词、工具定义、模型配置、消息前缀和思考配置必须与父 Agent 逐字节匹配
<br>
一些 Agent 框架在派生子 Agent 时，使用不同的上下文或提示词，这样就不要求字节级对齐
工具结果的替换字符串在首次出现时就被冻结
当大型工具输出被替换为摘要预览时，替换后的字符串会被持久化保存
即使后续会话重启，系统也会使用完全相同的替换字符串
以保证恢复后的消息序列与缓存中的字节流一致，避免缓存失效
核心启示
在设计 Agent 架构时，缓存经济性不是事后优化，而是前置约束。越早将这个约束纳入架构设计，后续的工程代价越小
提示工程：优化系统提示词
提示工程（Prompt Engineering）
核心对象是系统提示词（System Prompt）
API 消息列表中那条 role: "system" 的消息
它是 Agent 的“员工手册”，定义了 Agent 的身份、行为规则、约束条件和工作流程
一个精心设计的系统提示词，能让模型在具体任务中充分发挥其通用能力
优化系统提示词
语气与风格：系统提示词的“人格”
语气和风格的设计是提示工程中最容易被忽视，却又深刻影响用户体验的部分
过度使用会导致效果被稀释，应保留给真正关键的约束
结构化提示：系统提示词的“格式”
现代大语言模型对结构化输入展现出显著的敏感性，这源于训练数据中包含大量的结构化内容
XML 标签
使用遵循层次化原则，其标签名称本身就携带语义信息——<working_directory> 能立即告诉模型这是工作目录信息
Markdown
在保持可读性的同时提供了轻量级的结构，特别适合组织层次化的指令和信息
XML 和 Markdown 配合使用
可以形成一种双层结构
XML 负责机器可解析的精确语义
Markdown 负责人机共读的组织逻辑
Markdown 的作用
#、## 这些标题让人类一眼看出层次结构，可读性好
XML 的作用
<file_operation>、<network_request> 这些标签告诉模型“这个块是关于文件操作的”、“这个块是关于网络请求的”，语义精确，模型处理起来更准确
流程驱动 vs 规则堆砌：系统提示词的“组织方式
流程驱动的提示词
提供了清晰的标准操作流程（SOP）
业务规则细化：系统提示词的“内容”
模糊的规则会导致 Agent 的行为极不稳定
将决策规则明确到可执行的程度
提示词一般由产品经理来设计，基于线上数据分析、用户反馈和运营经验来迭代优化规则定义
工程师的角色是将规则准确地编码到提示词中，确保格式正确、结构清晰，但不应擅自决定业务逻辑
核心的设计哲学
大语言模型的优势在于遵循复杂指令和从长上下文中提取信息，但不应该在业务规则制定上被赋予过多的自由裁量权
通过清晰的操作框架解放模型的认知资源，使其专注于真正需要思考的部分
Few-shot 示例：何时给模型看例子
当期望的输出难以用规则精确描述,与其堆砌冗长的文字定义，不如直接给出两三个高质量的输入-输出示例
模型会凭借上下文学习能力从示例中“临时学会”这些模式，其效果往往胜过等量篇幅的抽象规则
工程上有两个决策点
示例位置
放在系统提示词中，示例成为静态前缀的一部分，对所有请求生效
也可以伪造一组 user/assistant 消息放在首轮对话中，适合按会话类型选用不同示例集的场景
示例对 KV Cache 前缀稳定性的影响
无论放在哪个位置，示例都处于上下文靠前的区域，一旦确定就应当保持字节级稳定
示例的数量也不是越多越好：两三个精心挑选、覆盖边界情况的示例
工具定义的设计
工具定义（tools 字段）
工具定义的质量直接决定了 Agent 使用工具的准确性
“工具定义与系统提示词一起构成静态前缀”描述的是基础模式
遵循 Skills 的渐进式披露思路：静态前缀里只保留工具的名称和简述，完整 schema 在模型按需请求后追加到上下文末尾，成为轨迹的一部分。
提示注入：上下文安全的核心威胁
提示注入（Prompt Injection）是 Agent 安全的核心威胁之一。其本质是：攻击者通过 Agent 处理的外部内容（网页、邮件、文档等），将伪装成系统指令的文本混入上下文，从而劫持 Agent 的行为。
防御的核心是帮模型分清“指令”与“数据”
来源标记
在外部内容注入上下文之前，用明确的标记包裹并标注来源
结构化角色
严格利用 Chat Template 的角色体系（system/user/assistant/tool）传递信息，让模型依据训练时建立的优先级区分可信指令与外部数据
输入清洗
过滤外部内容中的可疑模式
上下文层的防御
上下文层的防御（来源标记、指令与数据分离、输入清洗）只是第一道防线，它只能降低攻击成功率，无法做到万无一失
执行层的防御——权限控制、沙盒隔离、对高风险操作的独立审查
动态提示词与 Agent Skills
Skills：领域能力的可组合单元
定义
Agent Skills 的核心思想是将 Agent 的能力模块化为独立的、可按需加载的知识包
每个 Skill 本质上是一套包含专业领域指导的提示词集合
Skills 采用了渐进式披露（Progressive Disclosure）的设计哲学
结构流程
第一层（元数据）
每个 Skill 必须包含一个 SKILL.md 文件，开头是 YAML frontmatter; name 和 description 两个字段
目录的共同作用是提供可发现性，而不是承载完整的领域流程
元数据中的 description 字段是路由决策的关键
可以明确写出“何时使用”和“何时不使用”的边界
给出几条典型反例，以减少宽泛匹配带来的误触发
第二层（核心流程）
当 Agent 判断某个任务需要特定的 Skill 时，运行时才加载完整的 SKILL.md
触发加载的方式有两种
用户显式输入斜杠命令
模型读过元数据目录后自己判断需要某个 Skill 时，则调用专用的 Skill 工具
第三层（细则）
通过文件引用深入到更详细的子文档
Agent 会根据具体的需求选择性地深入阅读相关的子文档。
编写一份可用的 Skill
Skill 建议包含四个部分
角色与读者
说明这份 Skill 服务谁、面向什么任务，以及输出应达到什么标准
核心原则
只保留三到五条最重要的判断，并为关键原则配正例和反例
禁止清单
记录高频错误、越权动作和容易误解的表达，同时写清合法例外
参考资料
放术语表、模板、范文和更详细的子文档
规则应尽量写成 “作用域 + 动作 + 例外 + 验证方式”
写作型 Skill
可以从三到五篇自己最满意的原创文章开始
让 Agent 归纳用词、句式、段落结构和语气，生成一份二十行左右的初版
再用它处理一项真实的写作任务，由作者逐句改稿
原文与修改稿的差异比抽象地说 “更自然一点” 更有信息量：它能告诉 Agent 哪些词被删掉、哪些长句被拆开、哪些地方需要补充事实
把反复出现的改动整理回 Skill，并为每条规则保留正例、反例和适用范围
Skill 不仅包含指导性的文档，还可以捆绑可执行的代码工具和模板文件
Skills 的价值不仅在于优雅的上下文管理，更在于为领域知识的积累提供了一条可持续的路径,每个 Skill 都是自包含的知识模块，可以独立开发和测试，也可以单独进行版本控制，便于分享
Skills 在上下文中的位置
把 “元数据目录” 和 “完整 Skill 指令” 分开
标准层
规范规定的是加载时序，而不是消息角色
目录必须先于正文可发现，正文在 Skill 被选中后按需加载
具体消息角色、包装方式以及目录是否在每轮重建，都由 Agent Harness 决定
Claude Code 的实现
采用渐进式目录与调用时追加正文的方式
目录作为运行时上下文消息提供
完整指令则在 Skill 被调用的位置作为 user message 注入
OpenAI Codex 的实现
Codex 在每轮上下文构造阶段重新渲染 Skills catalog
并将其作为 developer 上下文片段提供
显式选中的 Skill 正文则以带 <skill> 标记的 user 片段注入
其他来源的 Skill 也可以通过专用工具按需读取
Skills 与工具的关系
Skill 的内容通过前述的渐进式披露机制按需加载，不会影响已缓存的前缀
把所有专用代码工具的定义都放在系统提示词中，数量膨胀会消耗大量的 token，而且会干扰模型的注意力
在 Skill + 通用执行器的模式下，工具数量始终很少
Agent 状态栏：通过元信息增强 Agent 轨迹管理
Agent 状态栏（Agent Status Bar）机制
Agent 框架把这些动态信息整理成结构化摘要并注入上下文
状态栏通过在上下文中嵌入结构化的元信息，为 Agent 补上自我感知和自我调节的机制
Agent 状态栏对模型起着完全相同的作用：它不是对话的主体内容，而是 Agent 框架在上下文末尾持续注入的状态摘要
Agent 状态栏的理论基础
源于注意力机制的一个本质特性：上下文学习更像检索而非推理
把分散在上下文各处的隐式状态提炼为可直接使用的显式知识
原始轨迹中的信息是高度冗余的
Agent 状态栏主动提取这些关键状态
特别是在复杂的 Agent 轨迹中，早期设定的任务目标和关键约束容易被后续大量的工具调用结果所淹没
模型会过度关注最近的上下文内容，而对位于上下文中部的信息产生“注意力衰减”现象
状态栏可以大大提高模型的思考效率，让每次 Agent 迭代的思考 token 量、延迟和花费均降低约一个数量级
Agent 状态栏的构成
任务规划
引入 TODO 列表，将任务分解为清晰的步骤，再把列表放在轨迹末尾，不断提醒模型当前的进展和后续目标，确保行动与总体规划保持一致
事件的侧信道信息（Side-channel Information）
为每个事件附加元数据——精确的时间、地理位置、距上次 Agent 回复的时间间隔等
帮助模型理解事件的时序关系和环境背景，从而做出更符合情境的决策
环境当前状态的观察摘要
包括动态的环境信息、异常操作提醒、以及从隐式状态到显式观察的转换
致力于让用户清晰地感知系统的当前状态
Agent 状态栏在上下文中的具体位置
Agent 状态栏在 API 层面实际上是作为一条 user 角色的消息插入到上下文末尾的
Harness 是在借用 user 角色这个消息槽位，向模型注入由 Agent 框架自动生成的系统状态信息
复用了 user 角色的消息格式来挂到上下文末尾
防止破坏整个前缀的缓存
用 <agent_status> 标签包裹以便模型识别其特殊性质
状态更新的两种实现与缓存代价
每轮替换
从消息列表中移除上一轮的状态消息，在末尾追加最新状态
移除旧状态会使其位置之后的所有缓存失效
状态较大、更新频繁或轨迹很长时
持久追加
状态消息一旦注入就永久留在轨迹中，每轮只在末尾追加新的状态
陈旧的状态会在上下文中累积，既占用 token，也要求模型自己关注 “最新一条” 状态而忽略已过时的旧状态
状态很小、两次更新间产生的消息很多，且会话长度受控时
好用的 Agent 状态栏技术
时间戳跟踪
以 [2025-09-14 10:30:45] 格式作为前缀添加到用户消息和工具响应中
使 Agent 能够理解时序关系，也为调试和审计提供了信息
工具调用计数器
维护一个全局字典，记录每个工具被调用的次数，并在响应中标注 “Tool call #3 for 'read_file'”。
其深层价值在于实现了隐式的成本感知
TODO 列表管理
写清单和更新TODO
每个 TODO 项包含唯一标识符、内容、状态,和时间戳
详细错误信息
错误类型和描述、完整参数的 JSON、调用栈信息，以及针对性的修复建议
系统状态感知
操作系统信息使 Agent 能做出平台相关的决策
组合场景
时间戳和工具计数器的结合使 Agent 能够理解操作的频率和时间分布
TODO 列表和系统状态的结合使 Agent 能根据环境调整任务策略
详细错误信息和工具计数器的结合使 Agent 在多次失败后不仅能改变策略，还能理解失败的原因
Agent 状态栏技术有一个实用的优点
所有元信息都以人类可读的形式出现在上下文里
开发者随时可以检查 Agent 获得了哪些信息、做了什么决定
更重要的是，它对模型没有侵入性——不需要微调，直接在任何语言模型上都能起效
状态栏的维护
状态栏尽量用代码维护，实在要用 LLM，也要逐条抽取、再由代码汇总，绝不要让它一次性批量统计
谨慎删除原始上下文
上下文压缩策略
设计压缩策略
解决长度约束和成本约束
上下文窗口有限
提升思考质量 --- 总结后的知识比原始形式更利于模型使用
缓解模型的上下文焦虑（Context Anxiety）
模型认为上下文窗口即将耗尽时，可能在任务尚未完成前提前收尾
上下文学习的内部机制：检索而非推理
把需要思考才能得到的结论，变成可以直接检索的知识
上下文腐化（Context Rot）过多的上下文内容导致注意力分散 关键信息权重变小
高密度知识表示 ,让模型不被动地在海量信息中检索，而要主动为模型提供经过提炼的结构化知识
压缩与 KV Cache：看似矛盾，实则互补
压缩发生的时机和位置
压缩不是在单次 API 调用的过程中修改上下文，而是在两次 API 调用之间
Agent 框架对消息列表进行预处理
System Prompt 和 Tool Definitions 永远不动
压缩的对象是对话历史中的 tool results
有意识的权衡
频繁压缩会频繁破坏缓存，最好在上下文接近阈值时批量压缩，而不是每轮都压
生产级的分层压缩机制
上下文管理系统通常包含五个层次,以 Claude Code 的做法为参照
工具结果预算控制
大体积的工具输出存到磁盘，模型只看摘要预览
替换决策一旦做出就被冻结，以保证缓存的一致性
噪声直接删除
低价值的内容直接移除,不做摘要
API 层微压缩
通过 API 层的上下文编辑能力，指示服务端从前缀中移除指定的工具结果，本地消息保持不变
归档式摘要
逐轮做结构化摘要,保留对话的逻辑脉络
全量压缩
由 LLM 驱动的完整压缩，作为最后手段
先尝试压缩会话记忆，不行再做全量压缩
全量压缩还配备了连续失败的熔断器
压缩策略的设计原则
提炼出指导具体压缩策略设计的四条原则
信息价值的非均匀分布
关键的决策点
支撑性的证据
冗余的噪声
语义完整性
不可丢失的关键信息
任务相关性
理想的 Agent 应能按任务类型自适应地选择压缩策略
检索类任务要保留广度
分析类任务要保留深度
创作类任务要保留灵感触发点
压缩即理解
显式压缩的结果可审查、可跨会话复用
Agent 需要定期将进展记录到文档中，而不是把所有信息零散地放在 Agent 执行历史中
Agent 也需要养成记录和更新文档的习惯
隔离优于压缩：子 Agent 上下文隔离
思路
让大体积的中间信息根本不进入主上下文
产生海量中间内容的任务，委派给一个独立的子 Agent
用隔离代替压缩
压缩是有损的、需要额外 LLM 调用的事后补救
隔离则让噪声从一开始就与主上下文绝缘，主 Agent 的 KV Cache 前缀也完全不受影响
代价是子 Agent 看不到主 Agent 的完整上下文，任务描述必须自包含、目标明确
用户记忆和知识库
<br>
用户记忆系统
定义
要让 Agent 跨会话提供个性化服务，需要一层持久的用户记忆
记忆能力的评估：三层次框架
综合 LoCoMo 等各类记忆基准与商业记忆产品的实践，用户记忆能力可归纳为以下八项
个人信息保留
记住用户身份等长期个人信息
偏好追踪
跟踪并记住用户的长期偏好
上下文切换
在多个话题之间切换时保持连贯
记忆更新
当用户提供与旧信息矛盾的新信息时能正确处理
多会话连续性
跨会话保持知识
复杂思考
基于多个记忆片段联合思考
时间感知
记住日期、理解相对时间、进行时间计算
冲突解决
识别并处理记忆之间的不一致
Agent 场景的三层次评估框架
基础回忆
要求 Agent 能够准确存储和检索用户直接提供的、结构化的、无歧义的信息
多会话检索
Agent 在面对来自不同对象、不同时期的多段会话时，能检索出所有相关信息并推理判断
主动服务
要求系统综合来自多个会话、甚至很久以前的信息，提供具有预见性的主动帮助，从看似无关的记忆中发现深层联系
记忆的层次结构
轨迹（Trajectory）
是一次 Agent 运行过程中的完整历史记录
“动态轨迹”（用户消息 + 模型回复 + 工具执行结果，也称 trajectory）
只增不改
描述的是用于追溯、调试或审计的原始事件记录
轨迹为 Agent 决策提供即时上下文
轨迹是单次会话的完整原始记录，按时间顺序追加且不修改
用户长期记忆则是跨会话提炼出的稳定信息，会被反复改写、合并、淘汰。前者是流水账，后者是档案
用户长期记忆
跨会话、跨实例的持久化存储，通常以键值对形式与特定用户 ID 绑定，其中存储着偏好设置、历史交互摘要和提取的知识点
Agent 通过特定工具调用显式读取和更新长期记忆，实现跨会话的个性化和连续性
分层设计既保证 Agent 高效处理当前任务（依赖轨迹），又使其具备长期个性化能力（依赖长期记忆）
用户记忆的四种存储格式
Simple Notes
体现极简主义设计,每条记忆是一个最小的、不可再分的事实
处理需要综合多条信息才能回答的查询时，系统需要重新拼凑碎片
Enhanced Notes
采用整体视角，将每条记忆保存为包含完整上下文的段落
这种表示保留了信息的叙事结构，确保语义完整而丰富
但代价是存储冗余,更新复杂
JSON Cards
三层嵌套结构 类别→子类别→键值对 模拟人类对信息的分类方式
支持部分更新,刚性结构假设信息可清晰分类,强制归入单一类别会丢失多维性
Advanced JSON Cards
代表了记忆系统从信息存储到知识管理的范式转变
记录事实
叙事背景
主体身份
用户的关系
时间戳
同一条信息在不同场景下可能有完全不同的含义
代价是生成和维护成本较高
实践中的选择标准
关键且少量的数据（如用户偏好、关键人物关系）用 Advanced JSON Cards 以保证可检索性
大量且非关键的对话事实用 Simple Notes 以降低成本
多数生产系统采用混合模式——同一 Agent 内不同类别的信息走不同路径
进阶知识表示形态：可执行代码
User as Code
把用户状态改成带类型的可执行对象，并把规则写成普通函数，让“表示”和“推理”使用同一种可验证介质
会话结束后先把事实追加到只增日志
再定期从完整日志重建带类型的状态
用户记忆的认知科学基础
工作记忆
工作记忆对应 Agent 的上下文窗口——用于处理当前任务的临时信息空间
长期记忆
情景记忆
关于具体事件和经历的记忆
语义记忆
从具体事件中抽象出的一般性知识
程序记忆
关于行为模式和流程的记忆
记忆框架案例
Mem0
v2
提取、对比、决策
对话结束后，LLM 先抽取候选事实
系统再用向量检索找到相近的已有记忆
由 LLM 在 ADD、UPDATE、DELETE、NOOP 中做出决定
用实体—关系图支持多跳与时序问题
风险则是一次错误的更新或删除会不可逆地丢失历史信息，而且每条候选事实都要经历检索和第二次 LLM 判断
v3
仅追加写入、混合检索
当前管线用一次 LLM 调用抽取事实，并且只做 ADD
查询时，系统融合语义相似度、BM25 关键词和实体匹配，并结合时间信息排序
Agent 确认完成的动作也成为一等事实;避免错误 UPDATE/DELETE 丢失历史，又减少 LLM 调用
还能用多种检索信号和时间排序找出当前事实
Memobase 用户画像与事件记忆
用户画像（Profile）
是一组可由开发者配置的槽位，按主题—子主题两级组织
存放从对话中提取的稳定用户属性
开发者可以精确控制画像的范围和粒度
事件记忆（Event Memory）
则按时间线记录用户经历的事件
Memobase 采用缓冲批处理策略
对话先在缓冲区累积
达到一定规模或时限后再统一触发一次记忆提取
以摊薄 LLM 调用成本
多类型记忆协同的参考架构
是情景记忆的多维元数据检索
它存储带有丰富元数据（时间戳、情感标记、任务标识）的事件序列，可按时间、主题等多个维度组合检索
工作记忆
管理当前任务状态，与长期记忆动态交互
重要信息选择性转移到长期记忆
相关长期记忆被激活并加载到工作记忆
记忆压缩与整理机制
采用多层次的记忆压缩策略
通过重要性评分筛选
访问频率
时间衰减
情感强度
信息独特性
采用聚类
相似记忆被分组，每组生成代表性摘要
原始详细记忆可存档到二级存储
抽象和泛化
从具体情景记忆中提取一般性规律，转化为语义或程序记忆
隐私保护：日志脱敏
核心挑战是让 Agent 既能利用用户信息提供个性化服务，又不让敏感数据暴露在 LLM 上下文和系统日志中
RAG 基础：构建 Agent 的知识获取管道
定义
检索增强生成（Retrieval-Augmented Generation, RAG）
核心思想
将大型语言模型的思考和生成能力，与外部知识库的广度和时效性相结合
核心流程
检索相关片段 → 注入上下文 → LLM 基于上下文生成答案
文档分块（Chunking）
离线预处理——分块（Chunking）;把长文档切成适合独立检索的片段
分块原因
嵌入模型对输入长度有限制文档且只压缩成一个向量时，多个主题混在一起，向量无法精确表达任何一个
检索的目标是只把相关的那部分注入上下文，片段太大会连带引入大量无关内容，浪费窗口、稀释注意力
分块策略
固定大小切分
最简单的方法，按固定的 token 数切分
通常在相邻块之间保留一定重叠
避免关键句子恰好在边界处被切断
递归/结构感知切分
按文档的自然边界递归切分
先尝试按大边界切块，仍超长时再降级到更小的边界
Markdown、HTML 这类有显式结构的文档尤其适合
语义切分
计算相邻句子的嵌入相似度,在语义“断崖”处（相似度骤降的位置）下刀
使每个块内部主题尽量单一
切分质量更高，代价是需要额外的嵌入计算
嵌入Embedding
嵌入定义
把每个词或句子转化为向量数字
让语义相近的内容转化出来的数字串也“相近”
向量所在的数学空间称为“向量空间”
向量运算可以捕捉到语义关系
余弦相似度
它计算两个向量夹角的余弦值，值越接近 1 表示方向越一致、语义越相似
早期 Word2Vec
只能捕捉词汇共现关系
通过分析海量文本中词汇的共现关系，为每个词生成一个固定向量
现代（BERT、BGE-M3）
上下文感知模型
能理解上下文，同一个词在不同语境下会有不同的向量表示
注意力（Self-Attention）机制
模型在计算每个词的向量时，会同时参考句子中所有其他词的信息
BGE-M3
实际同时输出稠密、稀疏、多向量三种表示
夹角
两个向量的方向是否一致（语义是否相近）
长度
文本的长度或频率
构建向量检索服务
ANNOY（基于树）算法
构建速度
快
内存占用
低
增量更新
不支持(须完全重建)
查询精度
较高
适用场景
数据不常变的静态数据集
HNSW（基于图）算法
构建速度
较慢
内存占用
较高
增量更新
支持（但长期增量插入后建议定期重建以保持查询精度）
查询精度
极高
适用场景
需要实时索引新信息的动态场景
稠密嵌入：从词汇关联到语义理解
用深度学习把文本映射到向量空间——语义相近的内容，向量距离也近
稀疏嵌入：精确匹配的关键词检索
根植于传统信息检索，核心是精确的关键词匹配
TF-IDF 词频–逆文档频率
一个词在当前文档中出现得越多、在整个语料库中越少见，它对检索越重要
长文档也容易仅仅因为字数更多而获得高分
BM25
它保留 IDF 对稀有词的加权，同时引入词频饱和与长度归一化
控制词频饱和速度，使重复出现的边际贡献逐渐降低
控制长度归一化强度，使不同长度的文档更公平地比较
不含该词的文档数
混合检索：两全其美的艺术
典型的混合检索流水线包含三个阶段
并行检索
系统同时向稠密和稀疏两个引擎发送查询，各自召回一部分候选文档
结果融合
负责把两路结果合成一个统一的候选池
常用的融合方法是倒数排名融合
抛开原始得分、只看排名,各路结果中排名的平滑倒数之和
神经重排序（Neural Reranking）
它让跨编码器对查询和文档做深度交互匹配
精度远高于检索阶段双编码器各自独立编码
再靠向量运算比相似度的做法
注意重排序并不替代融合：融合负责从两路结果中产生统一的候选池，重排序负责在这个候选池上精排
重排序器
“跨编码器（Cross-Encoder）”架构
双编码器为查询和文档独立生成向量,通过向量运算计算相似度，速度极快，但无法捕捉深层的匹配关系，适合从海量数据中做初步筛选
跨编码器则把查询和候选文档拼接成一段完整的文字送入模型，让模型逐词比对、输出一个综合的相关性得分，慢得多，但判断更准确
检索质量的三个核心指标
recall@k（召回率@k）
包含正确答案的文档出现在前 k 个检索结果中的查询比例
MRR（Mean Reciprocal Rank，平均倒数排名）
每个查询取第一个相关文档排名的倒数，再对所有查询取平均
nDCG（normalized Discounted Cumulative Gain，归一化折损累积增益）
综合考虑所有相关文档的排名与相关程度，排名越靠后的相关文档得分折扣越大
超越扁平文本：知识的组织与检索
定义
超越扁平文本块,构建能反映知识层次与关联的结构化索引
结构化索引：从信息检索到知识建模
结构化索引的思路
索引之前先用 LLM 把知识整理一遍——归纳、抽象、建立关联;多花一些计算资源，换取更好的检索质量。业界目前主要有两条路
树状层次（RAPTOR）
采用自下而上的递归抽象方式
首先将长文档切分为小的文本块作为“叶子节点”
通过聚类算法将语义相近的叶子节点分组,每一类就代表一个主题
根节点 全文摘要
这种树状结构使得检索可以在多个抽象层次上进行，既能精确回答细节问题，也能提供对宏观概念的理解
实体关系图（GraphRAG，Graph-based RAG，基于知识图谱的检索增强生成）
GraphRAG
定义
将文档知识建模为由实体（Entities）和关系（Relationships）构成的知识图谱
知识图谱通过实体-关系-实体三元组（Triple）构建信息网络
大量三元组交织在一起，就形成了一张知识之网
多跳关系推理
在扁平化的记忆存储中，这类多跳查询要么需要多次独立检索再由 LLM 拼接（效率低且容易断链）
知识图谱的图结构天然支持沿关系边遍历
实体消歧（Entity Disambiguation）
不同节点，通过各自的关系边连接到不同的人和机构，消歧过程无需额外推理
知识图谱面临固有局限
将自然语言转为三元组不可避免地导致语义降级
核心的条件逻辑和时间依赖全部丢失了
三元组提取的准确性高度依赖 LLM 的理解能力，错误提取会导致知识污染
实践中的推荐策略分层互补
以完整自然语言保存核心信息（保留语义完整性）
辅以结构化元数据进行索引和检索（兼顾查询效率）
在需要多跳推理和精确消歧的垂直场景,将知识图谱作为专项索引手段，与自然语言记忆协同工作
文件系统范式：用目录结构组织知识
文件系统范式
它不将上下文视为扁平的向量碎片或图谱节点，而是将所有上下文——记忆、资源、技能——映射为虚拟文件系统中的目录和文件，每个条目拥有唯一 URI
核心设计L0/L1/L2 三层上下文按需加载
L0（摘要）
L1（概览）
核心信息与使用场景，供 Agent 规划决策
L2（全文）
为完整原始内容，仅在需要深入时按需加载
选择 Markdown 纯文本而非专用数据库作为知识的底层表达
文件之间必须建立起链接与索引
不同模型主动建立这类链接的意愿与能力并不相同 ,需主动要求
知识应该如何更新
用户记忆和知识库的增量更新<br>
把知识库当成代码库，把每次知识变更当成一个 Pull Request（PR）
提议者—审核者模式
Proposer Agent 提交 PR
它从原始证据中发现新事实、冲突或过期内容，在工作分支上提出尽可能小而完整的 diff
先检索相关的已有知识，再增、删、改对应条目
同步维护链接、索引、时间元数据和证据引用
Reviewer Agent 独立审核
它拿到变更前的知识、diff 和原始证据
独立检查每个新断言是否能被证据支持、是否遗漏限定条件、是否与其他文件冲突，以及删除或改写是否过度
审核不通过时，它应返回指向具体证据和行号的可执行意见
双方迭代至收敛
Proposer 根据拒绝理由修改 diff，Reviewer 再次回到原始证据复核
只有 Reviewer 明确批准，PR 才可合入
同时要设置最大迭代次数或成本预算；超出上限仍未收敛时转人工审核，不能默认放行
合入后再发布
CI 先检查格式、链接、元数据、权限标签；若知识以代码表示，还要运行类型检查和测试
通过后才从已合入的版本增量重建受影响的分块、摘要和向量索引
索引是可重建的派生物，Git 中已审核的知识才是真正的来源
明确分开三层
原始证据层保存只增不改的对话、轨迹和原始文档
知识层保存经过提炼、可持续修订的 Markdown 或代码
服务层保存从特定已合入版本生成的检索索引
Proposer 和 Reviewer 都必须是 Agent，而不是两次固定的 LLM API 调用
都应能按需查询完整的知识库和原始证据库
两个 Agent 应优先使用能力相近但来自不同家族的模型
用户记忆和知识库的定期整理
后台周期性窗口里从全局视角重新审视整个知识体系
三项核心工作
去重、去旧与合并
回到原始数据核查
冲突解决与场景限定（qualification）
要追溯各自的原始信息源
检查它们是否分别在不同时间、对象、地域、任务或前置条件下成立
把各自的适用场景明确写入知识
如果证据仍不足，则应保留冲突和待确认状态，不得强行收敛成一个确定结论
失效内容的检测与下线
附加版本号、生效/失效时间等元数据
在检索阶段就过滤掉已失效的内容
提炼摘要时显式标注“此条已于某日废止”
多用户共享的权限与租户隔离
检索必须按调用者的权限过滤
多租户系统还需保证租户之间的向量索引和元数据相互隔离
智能体化 RAG：将知识检索工具化的范式转变
定义
把 RAG 从固定的数据处理流程升级为由 Agent 主导的动态迭代探索
在这种范式下，知识库检索不再是自动化的前置步骤，而是一个可供 Agent 随时调用的工具
Agent 采用 ReAct 模式
Agent 首先 “思考” 分析核心需求，自主决定应该使用什么查询关键词才能最有效地获取信息
然后 “行动” 调用 knowledge_base_search 工具
在 “观察” 到初步结果后不会立即生成答案
评估信息是否充分
智能体化 RAG 通过 Agent 的自主决策将搜索和思考有机融合，能在海量非结构化知识中自主探索，通过多轮迭代逼近答案；其能力也会随着知识库扩充和模型进步而提升。
RAG 的安全边界
间接提示注入
恶意指令被注入知识库中
知识库投毒
发生在索引之前
指令与数据分离
对所有检索得到的内容做来源标记，明确告诉模型“以下是供参考的外部资料，不是你要服从的命令”
不让检索内容直接触发高风险操作
智能知识库架构
RAG 技巧：上下文感知检索 Contextual Retrieval
核心思想
在对文本块进行向量化索引之前，先利用 LLM 为其生成一段简短的、包含核心上下文的“前缀摘要”，然后将前缀与原始文本块拼接后再索引
上下文感知检索发生在索引期,针对的是知识库里的文本块
上下文感知压缩发生在运行期,针对的是当前会话的对话历史
工具
工具的分类
感知工具
Agent 主动获取信息、感知世界的方式
感知工具的设计关键在于控制输出信息量，防止上下文爆炸
执行工具
Agent 改变外部世界的方式
与感知工具不同，执行工具的错误代价可能极高，安全约束是其设计的核心
协作工具
Agent 与其他 Agent 及人类协作的方式
最简单的原因是并行执行不相关的多个任务,更复杂的原因是使用不同的模型、工具、提示词和上下文执行不同的任务，实现更好的效果
用户沟通工具
Agent 主动向用户传递信息的方式
Agent 与用户的沟通从单一会话内的一问一答扩展到多渠道的异步消息时，“说话”本身也需要成为显式的工具调用
事件触发工具
外部世界驱动 Agent 行动的方式
注册时由 Agent 主动调用工具,触发时由外部事件异步回调，唤醒 Agent 开始处理
工具设计的通用原则
定义
ACI（Agent-Computer Interface）
工具应该对应 Agent 的目标，而不是底层的 API 操作
能力的表达形式：专用工具、通用执行器与 Skill
专用工具
结构化的函数调用，确定性高、可测试、参数受 schema 约束
代价是每个工具的定义要占去数百个 token
Skill
用自然语言编写的 Skill 文档来描述操作流程
Agent 通过终端或代码解释器来执行,少量的通用工具就能覆盖大量场景
通用执行器
通用工具优于专用工具，除非存在明确的安全、权限或性能理由
提供通用工具相当于给 Agent 一个“元能力”,利用LLM 本身具有强大的思考和代码生成能力
四个决策维度
安全与权限
需要精细授权、审计留痕，或有不可逆风险的操作，用专用工具封装；其余情况优先通用
参数复杂度
涉及嵌套对象、多字段联合校验、复杂类型约束的操作，专用工具的结构化 schema 能更好地引导模型正确传参；参数简单的操作通过 CLI 命令传参同样可靠
变更频率
频繁变化的能力用 Skill 来维护，成本远低于专用工具；而稳定的底层操作更适合做成专用工具
模型能力
较强的模型可以用 Skill + 通用执行器的方式表达更多能力、减少工具数量；较弱的模型则需要结构化的工具 schema 来引导正确调用
工具描述的艺术
定义
工具描述的质量直接决定了 Agent 使用工具的准确性
工具描述的核心 是描述使用场景帮助 LLM 做出调用决策
清晰列出工具的边界条件
参数描述应该用具体例子代替抽象规范
返回值也需要描述清楚
每个工具附带 1-5 个真实的调用示例
当 Agent 频繁选错工具时，应优先检查工具描述而不是怀疑模型能力
参数传递的保真性
静默输入转换
工具在执行前悄悄地“修正”模型的输入参数，导致实际操作偏离了模型的意图
静默参数注入
工具在模型不知情的情况下向命令追加额外的参数
工具的参数传递必须保持透明，不得在模型不知情的情况下修改输入或输出
工具生态：MCP 与 Skill Hub
Model Context Protocol（MCP）
采用客户端-服务器架构
MCP 服务器暴露一组工具，MCP 客户端（通常是 Agent 框架或 IDE）通过标准化协议与服务器通信
关键的设计决策
标准化的工具描述格式
每个工具通过 JSON Schema 定义输入参数的类型、约束和描述，确保不同的客户端都能正确理解工具的使用方式
传输层的灵活性
MCP 支持本地和远程两种部署方式
本地传输采用 stdio（标准输入输出）
远程传输采用 Streamable HTTP
资源与工具的分离
MCP 还定义了只读的资源
使 Agent 能够区分“获取信息”和“执行操作”这两类不同性质的动作
提示模板（prompts）
由服务器提供的可复用提示词模板，供客户端和用户按需选用
<br>
MCP 的生态价值在于一次开发，处处可用
Skill Hub
skill 的分发机制是注册表（registry）而不是协议
专用工具和 Skill 的 token 成本不同
接入一个 MCP 服务器，是在运行时建立一条连接，它暴露的全部工具定义会进入每一次会话的上下文
安装一个 skill，只是往磁盘上拷一个文件夹，常驻上下文的只有目录里的 name 和 description
第三方能力的安全风险
工具描述投毒
工具的 description 会随工具定义原样进入模型上下文
恶意或被劫持的服务器
可能引入恶意行为,远程服务器还可能被入侵后篡改工具行为和返回结果
同名工具遮蔽
恶意服务器可以“遮蔽”正规工具，诱导 Agent 路由到攻击者手中
风险处理
审查工具描述
把 description 当作不可信输入来审计，而不是当作无害的元数据
锁定服务器版本
拒绝静默更新，升级时重新审查
最小权限的凭证
为每个服务器配置最小权限的凭证
工具太多怎么办：层次化组织与主动工具发现
层次化组织与按需加载
按需加载：只暴露索引
核心模块刻意不内置 MCP，优先建议把能力封装成带 README 的 CLI 工具
再由 Skills 按需加载
确实需要 MCP 生态时，则通过扩展接入
是否采用 MCP 作为互操作协议与是否在会话开始时暴露所有 MCP 工具定义是两个独立决策
层次化组织:按信息源的性质分类
搜索工具
主动查找信息
读取工具
从已知位置提取内容
解析工具
处理非结构化数据
查询工具
访问结构化数据源
检索式预筛选
按语义相似度先筛出一批候选工具再注入
模型原生的主动工具发现
从被动选择到主动发现
让 Agent 从被动接受者变为主动发现者：在执行过程中意识到能力缺口时，主动用自然语言声明 “我需要什么能力”，系统再动态匹配并注入
是在系统提示词里只保留少数基础工具,外加一个 “工具搜索工具”
层次化匹配与降级
高效匹配的关键在于工具组织本身具有层次结构
先按能力描述定位相关服务器，再在服务器内匹配具体工具
工程上这依赖一个离线构建、支持增量更新的嵌入索引
动态加载与 KV Cache
把新工具的完整 schema 追加到上下文末尾
静态前缀保持稳定
schema 此后固定在轨迹的原位置
作为普通历史消息继续命中缓存
状态栏则只维护一份简短的工具名列表
工具定义必须在上下文最前面
<br>
Skills：把工具发现变成“按需查阅”
渐进式披露
Agent 启动时skill的目录,每个 skill 的 name 与 description
上下文按对应能力需要 ,模型读取对应的sub-skill,读取具体的脚本或子文档
感知工具
定义
感知工具是 Agent 获取外部信息的主要渠道，设计上需要在粒度、组织方式和输出格式等多个维度精心权衡
上下文感知压缩
当输出超过阈值,基于 Agent 当前的查询意图自动压缩
搜索类工具的返回格式与分页
搜索工具的返回值应该是结构化的候选列表
默认只返回前若干条，并在返回值中注明结果总数和获取下一页的方式，由 Agent 自主决定是否继续翻页，而不是一次性倾倒全部结果
读取类工具的 offset/limit 与截断策略
read 类工具应支持 offset/limit 参数，按需读取大文件的指定片段
当内容超过阈值必须截断时，应明确标示截断情况：注明省略了多少内容、如何读取剩余部分
静默截断是危险的——Agent 会误以为自己看到了全部内容，基于不完整的信息做出错误判断
只读性带来的工程红利
感知工具不改变外部世界
结果可以安全地缓存
多个感知工具调用可以放心地并行执行
多模态感知的输出形态
纯文字内容用文本提取，布局敏感的内容（UI 界面、复杂表格、设计稿）保留图像
多模态感知
原生多模态处理
通过专门的编码器将不同类型的数据全部映射到统一的高维语义空间
在原生支持多模态的模型中，模型可以直接 “看到” PDF 的页面布局、图表和文字，能理解图文之间的空间和语义关系
提取为文本
将多模态内容提取为文本（Extract to Text）。
通过专门工具将非文本内容转为纯文本，再输入语言模型
但提取为文本的代价是信息损失：所有版式、图表、图像信息都在提取过程中被丢弃。
工具化多模态分析
将多模态分析作为工具是一种比提取为文本更好的方法
它赋予 Agent 可对原始文件深入分析的工具
工具接受一个多模态文件和一个自然语言问题作为参数，返回自然语言描述的分析结果
工具内部可以使用多模态模型实现，这个多模态模型不一定需要很强的 Agent 能力，从而有更多技术选型空间
执行工具
安全机制的层次化设计
权限控制
文件操作限制为只能访问特定的工作目录
命令执行维护一份禁止命令的黑名单
外部 API 检查配额和速率限制
输入验证
在执行任何操作之前，检查所有参数的合法性
发现异常输入时立即拒绝，不尝试“智能”修正
提议者-审核者(Proposer-Reviewer)：独立模型的安全审查
高效实现
模型选择,提议模型和审批模型应来自不同的家族
两个模型的底层规则和约束必须完全一致，上下文也需要一致
将拒绝理由作为工具调用结果加入 Agent 的轨迹
事前审批
一个模型负责提议行动（Proposer）,另一个独立的模型负责审查并批准;将拒绝理由作为工具调用结果加入 Agent 的轨迹
任何不可逆的、影响重大的操作都可以从事前审批中受益
事后验证
在操作完成后，由审核视角检验结果的正确性
事后验证的要诀在于模态切换
Sidecar 机制：与主思考并行的安全校验
Sidecar
操作执行时实时校验安全性和可靠性
旁路的安全检查模块在每次工具调用前独立判断风险，同时尽量不拖慢主 Agent 的思考节奏
Sidecar 是一种伴随主 Agent 思考循环运行的轻量级 LLM 调用模式，它不审查主 Agent 的最终输出，而是对主 Agent 的行为做独立判断
流式输出并行
Sidecar 起门控作用,危险操作在 Sidecar 放行之前不会真正执行
提示注入
Sidecar 分类器接收结构化输入,识别是否为高风险操作
拒绝熔断器
当分类器连续多次拒绝操作时，系统不应无限重试,而应转为请求用户手动判断
让安全检查在用户体验层面“隐形”
安全检查可能增加延迟。为了提升用户体验，一种做法是把 “展示” 和 “放行” 两件事拆开并行
Sidecar 模式的另一个典型应用是构造和补充上下文
主模型在思考的同时，Sidecar 模型以旁路方式并行筛选相关的用户记忆、为较长的工具输出生成摘要、从数据库中提取用户的最新信息等
自动验证与反馈闭环
执行工具的另一个重要设计原则
如果操作结果可以被验证，就应该自动验证
执行-验证-反馈
将输出解析为结构化的错误列表，作为工具返回值的一部分返回给 Agent
长输出的截断与持久化
头部保留
通常包含初始输出或错误上下文
尾部保留
通常包含最终错误信息或成功标志
中间提示
完整输出已保存至.....
文件引导
如需完整输出，请使用XXXX工具读取该文件
执行环境的隔离与沙盒
通用执行工具
本质上允许 Agent 执行任意代码，需要特别的安全考虑。理想的实现方式是在沙盒环境中运行，与宿主机隔离
通用执行工具隔离强度递增排列
进程级隔离
对低风险的 Agent，可以直接在本地环境中执行代码
容器隔离
Docker 等容器提供独立的文件系统和网络栈，隔离更完整
但与宿主机共享内核，内核漏洞仍可能被利用来逃逸。
microVM/虚拟机
Firecracker 等 microVM 提供带独立内核的硬件级隔离，是运行完全不可信代码的最强层级。
容器和 microVM/虚拟机隔离环境还应设置 CPU、内存、磁盘、网络的使用上限，防止恶意或失控的代码耗尽所有资源
工具执行的可观测性
监控、审计和调试 Agent 的执行行为
Agent 框架应该对执行工具提供
详细的日志
审计追踪
性能指标
告警机制
幂等性与取消语义
幂等性
唯一标识
先查询后变更
不可逆操作
不同模型家族的模型和专用安全检查提示词做校验
执行阶段如果失败不能盲目重试，而要把详细的错误信息返回给 Agent 主模型重新规划
协作工具
子 Agent 的设计哲学
子 Agent 的核心价值在于专业化分工
每个子 Agent 可以独立优化提示词、工具集和知识库，无需担心相互之间的冲突
子 Agent 提示词的关键要素
角色定义要清晰
上下文来源要明确标注
FROM_MAIN_AGENT 主协调 Agent 给你的任务指令
[FROM_USER] 用户直接补充的信息
[TOOL_RESULT] 调用工具后的返回结果
任务边界要明确界定
Agent 间的协作机制
协作原语
启动与取消
spawn_subagent 创建子 Agent 并分配任务
cancel_subagent 在任务失去意义时,及时终止，避免继续浪费 token
消息传递
send_message_to_subagent 在子 Agent 运行期间向它发送补充指令或追问,子 Agent 也可以反向给主 Agent 发消息汇报进展或请求澄清
发现
list_agents 列出当前可用的 Agent 及其职责描述和运行状态
tools/list Agent 找到潜在的协作者
协作形态
同步调用
等待子 Agent 返回，适合快速完成的任务
异步调用
立即获得任务 ID，完成时通过事件通知
流式协作
子 Agent 持续发送增量消息，适合过程本身有价值的场景
多轮交互
子 Agent 主动询问、主 Agent 应答的对话式协作
人工介入的艺术
超时和降级策略
HITL（Human-In-The-Loop，人在回路，即在 Agent 的决策流程中加入人类审核环节）
设置超时阈值和默认行为
反馈循环的建立
HITL 不应是一次性的交互，而应形成学习循环
人类的批准、拒绝及其理由首先构成带证据的反馈数据
可归纳的判断原则可以进入知识库或 Skill
高维而隐式的偏好则可以形成后训练数据
Coding Agent 与通用 Agent
Coding Agent
Coding Agent 是Agent基本能力
代码生成不是少数专门化 Agent 的专利，而是每个通用 Agent 都该具备的基础能力
七个核心工具
Code Interpreter（代码解释器）
提供隔离的沙盒环境,安全执行 Python 代码
Bash Shell（命令行终端）
在终端中执行命令，如运行测试用例、处理特殊格式文件
读文件工具
读取代码、配置、文档、日志等
写文件工具
创建新文件或完全重写现有文件
编辑文件工具
对现有文件进行局部修改，是代码维护和迭代的核心操作
搜索文件名工具（Glob）
通过模式匹配快速定位文件系统中的目标文件
搜索文件内容工具（Grep）
在文件内容中搜索特定的文本模式
通用 Agent 的 Coding 内核
执行流程
读记忆
调工具
写代码
生成产物
文件系统作为 Agent 的中枢
文件系统远不止是数据存储——它是 Agent 记忆、知识和能力的中枢
Agent 的长期记忆存储在 MEMORY.md
按日期归档的 Markdown 日志
适用边界
以开放任务为目标的通用 Agent
深度调研、内容生成、数据处理这类任务边界不确定、产物形态多样的场景
垂直领域
任务空间相对封闭，核心架构围绕固定的业务流程、领域工具和对话策略构建，代码在其中更多是工具箱里的一件工具而非架构中枢
即便在后者，coding 也是重要的基础能力：精确计算、数据处理、规则校验都离不开它
Coding Agent 的整体流程
计划优先于行动.验证贯穿始终.文档与代码共同演化
项目文档化
Coding Agent 的工作始于对项目的系统性理解
主动承担文档化的责任,通过系统性地阅读代码库，识别主要模块、核心抽象、组件间依赖关系,生成包含架构概览、目录结构、测试运行指南的初始文档
知识的显式化是高效协作的前提
专用的形态
项目指令文件 CLAUDE.md、AGENTS.md、.cursorrules 等
每次会话开始时被自动注入上下文，相当于项目级的系统提示词
指令文件承载的是面向 Agent 的行为约定
任务理解与需求澄清
Agent 应通过探索性调研来澄清边界，必要时主动与用户对话
复杂性维度
需求本身的模糊性,实现路径的多样性,影响范围的广泛性
编写设计文档
设计文档是将抽象需求转化为具体实现计划的桥梁
编写设计文档本身迫使 Agent 深度思考，在投入大量编码前先在概念层面验证方案可行性
设计文档为人类提供了高效的介入点
Agent 完成设计文档后应提交给用户审查，等待批准后再继续
代码实现与测试
代码规范
获得设计批准后，Agent 遵循项目代码规范进行实现，复用现有抽象和工具，必要时进行适度重构以保持代码库健康
测试用例编写与结果测试
实现完成后立即进入测试驱动的质量保障环节
代码审查
Agent 对自己生成的代码进行批判性审视
文档同步与交付
Agent 按需相应更新架构文档,维护了项目知识库的完整性和时效性
Harness 工程在 Coding Agent 中的实践
落地为具体的工程组件
验收基线
测试套件、CI 管道（持续集成流水线，代码提交后自动运行的一系列检查）、代码审查标准
执行边界
Agent的模块边界、依赖规则、权限控制
反馈信号
自动化的对错判断,Linter（代码规范检查工具，能自动发现格式错误和潜在问题）输出、测试结果、类型检查错误
回退手段
Git 版本控制、沙盒隔离、快照回滚
适用分析
任务清晰度
目标明确
最佳区域：修复有测试用例的 bug
目标模糊
高效地跑偏：用 linter 优化“代码质量”
验证自动化程度
目标明确
吞吐量受限：代码重构需人工审查
目标模糊
难以启动：“让 UI 更好看”
目标明确且结果可自动验证，是最适合 Agent 发挥的区域；目标清楚但验收还得靠人盯，吞吐量的天花板就是人的审查速度；有自动化反馈但目标模糊，系统会高效地往错误方向跑；两者都缺，Agent 基本派不上用场;Harness 的目标就是把尽可能多的任务推向“目标明确 + 验证自动化”这个象限
业界实践
大规模代码迁移案例
知识必须存在于代码库本身
约束编码进 Linter 和 CI 而非写在文档里
验证和纠正全链路自动化
LangChain
仅通过优化 Harness（系统提示词、工具中间件、自验证循环）就显著提升了基准任务表现
用 Agent 分析失败轨迹来改进 Harness”的方法论，使 Harness 工程从人工经验驱动转向数据驱动
Anthropic
将长任务拆分为两个角色
初始化 Agent 负责把大任务分解为任务清单
执行 Agent 负责逐步推进并把中间成果,留给下一轮继续使用
故障与错误恢复
故障分类学：四层故障
API 层
限流（HTTP 429）、服务过载、请求超时、连接中断、输出触顶被截断
这类故障与任务内容无关，是基础设施的噪声
工具层
幻觉调用（调用了不存在的工具）
参数畸形（不符合工具的输入约束）
执行抛异常
工具反复返回同一个错误，而模型不加改变地反复重试
上下文层
上下文窗口溢出、压缩失败、轨迹结构损坏
控制流层
死循环（反复执行相同操作却毫无进展）
死亡螺旋（错误触发的恢复逻辑自身又调用 LLM、再次出错、连锁反应）
检测：先分类，再计数
可重试的错误
限流、过载、网络抖动
不可重试的错误
参数不合法、权限不足、工具不存在
维护一张错误到恢复策略的映射表
检测模式
重复调用指纹(工具名 + 参数)
相同指纹反复出现就是无进展循环的明确信号
连续失败计数
活性与完整性监控
静默卡死(连接建立成功但数据流停止)
看门狗机制 检测超时重试,每个长连接都需要活性信号，而非仅依赖连接超时
完整性监控则针对轨迹结构
发现工具调用缺少配对的结果消息时，系统会在注入上下文前自动修复配对关系，而不是把结构异常抛给模型或用户
恢复：分级升级，逐级透明
静默重试
可重试错误的默认动作
指数退避叠加随机抖动,避免大量客户端同步重试
区分前台与后台调用,辅助性后台调用失败则直接放弃
降级与接续
重试无效时，改变请求本身再试
消息末尾追加元指令,模型从断点接续生成
主模型持续过载时降级到备用模型
高成本模式被限流时暂时回落到标准模式
结构化数据错误反馈作为输入,模型自我纠正
错误处理的边界不是单次请求，而是整个恢复循环
接管：把没跑完的轨迹交给另一家模型
跨厂商接管能带走的是文字，带不走的是凭证
轨迹不该按任何一家的接口格式存储，而应保存为一份中立格式
每段思考拆成可移植的文字与不可移植的凭证两部分
工具调用只记录名称与参数，标识符在渲染成具体请求时按目标厂商重新生成
终止：每条恢复路径都要有上限
每条恢复路径都必须有明确的熔断上限
死亡螺旋
错误处理路径中的逻辑本身又调用 LLM，再次出错，引发连锁反应
在所有自动化机制之上还需要全局的终止与升级条件
最大迭代轮数
会话预算上限
连续失败超过阈值时升级到人工干预
Coding Agent 的实现技巧
并行工具调用、流式执行与级联中止
第一个工具调用的参数一经完整生成并通过校验，即可立即开始执行，无需等待模型生成后续的工具调用
故障处理
每个工具定义应声明自己是否支持并发执行（默认为否，失败安全）
当某个调用失败时
通过级联中止机制终止同一批并行启动且依赖该结果的其他调用
但不波及独立的调用和父级操作
上下文的精细化管理
文件读取层面
Agent 不应总是读取文件全部内容
对大型文件，工具应支持按行号范围读取特定片段,返回内容时附加行号标注，每行代码都以实际行号作为前缀
命令执行层面
终端输出的处理同样需要谨慎
保留输出的前若干行
保留后若干行
中间以一行提示替代
并说明完整输出已保存到临时文件供按需查看
环境信息的动态注入
每次推理前应在上下文末尾以 Agent 状态栏形式注入关键环境信息
当前工作目录
git 分支
最近提交记录
未暂存和已暂存的变更概览
作为动态的、追加式的 Agent 状态栏实时生成并注入
Agent 获得了“环境感知”能力，每个决策都基于对当前状态的准确理解，而非过时的假设
命令执行环境的状态持久化
维护一个持久化的终端会话,在 Agent 启动时创建并在整个交互过程中保持活跃
Agent 也应保留启动隔离终端的能力以支持并行任务
但持久化会话应是默认模式
即时的语法反馈机制
文件写入操作一完成，工具层就自动运行相应的 linter 或语法检查器，将检查结果作为工具返回值的一部分呈现给 Agent
Agent 可以在错误引入的那一刻就进行修正，而不需要等到运行测试时才发现问题
从 Coding Agent 到通用 Harness 设计原则
约束优先于指导
能用代码强制的规则就不要用文档建议
验证要自动化
人工审查是不可扩展的瓶颈,测试套件、代码质量检查、行为监控的基础设施的投入回报率远高于增加人力
反馈越快越好，越结构化越好
错误信息越详细、越接近错误发生的时刻，Agent 的纠正效率越高
回退要可靠
Agent 在安全网内操作才能大胆试错
Git 分支、沙盒环境、快照机制确保任何错误都可逆
约束的另一层目的：防止过程性错误
验收基线管的是结果对不对，执行边界管的是过程
约束的是动作而非仅仅是结果
Harness 护栏是外部约束
对可训练模型，过程惩罚是内部内化
工具编排：故障边界控制
原则是故障只在同一批并行调用内传播，不上升到父级操作
精细的故障边界控制避免了“一个命令失败导致整个任务中止”的脆弱模式
Coding Agent 中的搜索工具
正则表达式内容匹配（grep/ripgrep）
最传统的搜索方式，逐行扫描文件内容进行模式匹配
正则表达式用特殊符号描述文本模式的语法
支持文件类型过滤
路径模式过滤以减少噪音
根本局限在于只能找到字面上匹配的内容，无法理解语义
文件名模式匹配（glob）
在文件系统的路径结构中查找符合模式的文件
通过快速扫描整个文件系统建立项目的组织框架
语义代码搜索
结构感知的分块
代码有严格的语法结构，应按函数、类、方法等完整语义单元切分，而非按固定字符数盲目切割
混合检索
向量嵌入（稠密嵌入）擅长找到语义相似但用词不同的代码
关键词匹配擅长精确匹配函数名和变量名
通过重排序模型,合并排序
Coding Agent 中的文件编辑工具
差异描述 + Apply Model
差异变更描述
应用模型
负责与原文件合并、产出完整的新文件
主模型专注高层代码逻辑、应用模型专注底层文本操作
脆弱性在于合并环节
目前主流不用
旧字符串到新字符串（Old String → New String）
模型提供 old string（要被替换的原文）和 new string（替换后的新文本）,框架执行简单的字符串查找替换
代价是删除大段代码时需完整输出所有原始内容，一个字符的偏差就会匹配失败
同一代码出现多次时需提供更长的上下文来消除歧义
Claude Code、Codex 和今天 Cursor 采用的方案
行号定位（Old Line Numbers → New String）
模型指定 “删除第 X 到 Y 行，插入新内容
让模型在多次编辑中都使用初始行号来定位，以免出现混淆
类 Vim 编辑命令
借鉴 Vim 编辑器的命令体系，支持复制、剪切、粘贴等丰富操作
多个编辑,不断计算 比较复杂
字符串首尾匹配（Old String Start + End → New String）
提供要删除内容的开头几行和结尾几行，中间部分可省略
框架架通过匹配这个开头和结尾来定位替换区域，只要这对 “首尾” 组合在文件中唯一就能准确定位
同时因为仍然基于内容匹配而非抽象行号，模型犯错的风险相对较低
Coding Agent 的安全
核心问题
致命三要素
访问私有数据
暴露于不受信任内容
具备外部通信能力
持久记忆
四类边界
数据边界
输入信任边界
输出影响边界
跨会话边界
提示注入威胁
命令语义解析
沙盒隔离与网络出口控制
持久记忆的跨会话防线
隔离兜底：代码执行沙盒的工程选型
网络出口控制
默认断网，按需通过白名单代理放行有限目的地
文件系统隔离范围
源码目录以只读方式挂载
单独的可写工作区目录承载生成物和中间文件
凭证类文件根本不挂载进沙盒
资源限额与超时
限制资源的配额
超时时间阈值配置
超时和超限应向 Agent 返回结构化错误
安全：语义解析而非关键字黑名单
理解每个命令的参数类型和消费规则
识别出“某个看似无害的标志位实际上会消费下一个参数从而隐藏危险载荷”这类攻击模式
语义解析能识别出这些嵌套的危险操作
Agent 为谁效忠：多方委托下的忠诚度
委托方忠诚
对主Agent绝对忠诚，对外部交互方保持审慎
保证我方不被对方Agent 策反
代码：通用 Agent 的元能力
定义
元能力作用对象
思维本身
用代码替代易错的自然语言推理（思考工具）
业务规则
把模糊的政策编码为可执行约束（业务规则约束）
内容呈现
生成 PPT、视频与可视化产物（多媒体生成）
系统接口
桥接异构 API，自动适应数据格式演化（系统适配器）
用户界面
动态构造表单与交互界面（生成式 UI）
Agent 自身
用代码创造或修复新 Agent，形成自举
代码作为思考工具
让 LLM 负责理解问题并写出代码，让代码解释器负责精确计算
代码作为业务规则的约束
Harness 的核心原则之一是“约束：编码化而非文档化”
将规则从自然语言文档转化为可执行的代码，使其成为系统行为的强制约束而非建议性指南
代码生成使 Agent 能够自主完成这个转化过程
精确表达复杂业务规则
自然语言规则 vs 代码化规则：互补而非替代
将规则写在系统提示词中的优势
模型可基于规则向用户解释政策
可根据规则寻找变通方案
可在调用工具前初步判断可行性
将规则编码成校验工具的优势
代码逻辑具有精确性和无歧义性
代码执行具有确定性
复杂规则组合——多条件布尔组合、时间计算、跨数据源验证
系统提示词包含自然语言规则供理解和沟通，关键决策点配备代码化校验工具作为“守门员”确保合规性
防止不可逆的错误操作
合并校验与执行：checklist 引导思考，真值校验守门
参数作为思考的 checklist
填写参数的过程本质上是一个强制性 checklist
参数只是模型的自我陈述，服务端从不把它当作事实
服务端真值校验才是守门员
必须建立在模型无法伪造的数据之上
独立性不仅指独立的模型，更指独立的数据来源
三重保障
系统提示词的自然语言规则帮助理解和解释
工具描述与参数设计作为 checklist，引导模型在调用前显式核对条件
服务端基于数据库真值的代码化校验作为最后守门员
代码驱动的多媒体生成
定义
通过代码生成，Agent 绕开了视觉定位难题，获得对文档的精确控制能力
PPT 生成 Agent
把 PPT 创作转化为代码生成问题，就能极大降低复杂度
现代 PPT 框架（如 Slidev）采用优雅的设计哲学
用 Markdown 和 HTML 定义演示内容
创建一页幻灯片只需编写简洁的标记语言，框架会自动处理渲染、布局和动画
这种方式对掌握了代码生成能力的 Agent 极其友好
Proposer Agent 负责生成 Slidev 代码，理解内容逻辑结构并将其分解为合理的页面
Reviewer Agent 运行代码将每页渲染为图片，用 Vision LLM（能“看”懂图片的多模态大模型）从内容密度、可读性、布局合理性、视觉美感等维度分析渲染结果，生成结构化的改进建议
视频编辑 Agent
把视频编辑重构为 API 调用和代码生成问题则大幅降低了复杂度,以结构化、可组合的方式暴露核心功能
对 Agent 而言，将自然语言需求转化为 API 调用，远比理解 GUI 界面并模拟鼠标点击容易得多
3D 与工业零件：代码生成与生成模型的边界
工业零件天然有紧凑的精确描述
自然动植物 内在复杂度是近乎无限的
精度要求和可验证性
代码生成的零件可以程序化验证
表示形式和可编辑性
网格化和曲面化
代码作为系统适配器
Agent 系统的可观测性依赖于对执行流程的可视化
建立一个自动修复的反馈循环
当前端遇到无法解析的日志格式时，不是显示错误，而是自动将失败信息（原始日志样本、详细报错）报告给 Agent
Agent 分析样本数据结构，生成能正确解析的前端代码
代码先在虚拟浏览器中自动测试（验证解析正确性，用 Vision LLM 检查可视化效果），通过后热更新到前端系统
Agent 执行日志自动分析和问题诊断
代码生成为诊断提供了自动化路径
Agent 可以读取生产日志，结合架构文档和 PRD（产品需求文档）自动判断执行流程是否符合预期
定位有问题的环节和模块，再根据分析结果生成结构化问题报告（优先级、模块、描述、改进建议）和回归测试用例
测试用例引用问题轨迹 ID 和关键交互轮次，测试框架通过自动重放，验证修复后的系统在相同输入下能否产生正确行为
Agent 通过 MCP 对接 GitHub，创建 Issue 并分配给相关开发者，完成从问题发现到任务分派的全自动化
代码作为生成式 UI
A2UI 类协议：生成式 UI 的标准化
核心步骤
以 A2UI（Agent-to-User Interface）为代表的声明式界面协议提供了一种更安全的方向
Agent 不直接生成可执行的代码，而是只输出一份“界面描述清单”（JSON 格式）
客户端收到这份清单后，用自己预先准备好的安全组件来渲染界面
核心设计原则是安全优先
客户端维护一个受信任的组件目录
Agent 只能请求渲染目录中已有的组件，无法注入任意代码
客户端用自己的原生组件渲染，而不是执行 Agent 生成的任意 HTML
高度定制化的需求
用 HTML 交付成果：取代 Markdown 汇报
交互式演示：可以用可操作的形式直接演示系统是如何运行的，用户往往一看就懂，胜过大段文字描述
更好的数据可视化：用图表而非表格来呈现数据，还能构建交互式组件，让用户自行浏览、筛选、下钻到自己关心的细节
可持续完善的交付件：HTML 网站不必是任务结束时才一次性产出的死物，而可以在工作推进的过程中，由 Agent 不断补充和完善
交互式网站
实验数据追溯
训练指标监控
运行原理展示
澄清用户意图
当用户需求表达模糊或不完整时，Agent 需要通过澄清问题来收集必要信息
生成 SQL 查询
Artifact 模式
系统拿着这段 SQL 直接去数据库查询，把查到的数据渲染成用户能看到的表格
生成的 SQL 和可视化代码不能直接执行
执行层应使用只读数据库账号，解析 SQL 并只允许经过批准的 SELECT 语句，拒绝 DDL、DML 和多语句查询
用户提供的值应由服务端参数化绑定，同时限制查询时间、返回行数以及可访问的表和时间范围
视化代码应在隔离网络和文件系统的沙盒中运行，并且只能产生规定格式的结果
动态生成软件
用户提出需求，Claude 实时生成前端界面和交互逻辑，用户与生成的软件交互
Claude 修改代码生成新界面展示操作结果。整个过程中用户看到一个从无到有、持续演化的应用程序
代码创造代码：Agent 自举
让 Agent 编写 Agent 的关键技巧
常见缺陷
上下文管理的随意性
将轨迹转为纯文本塞进上下文，忽略结构化消息带来的 KV Cache 优化，工具调用循环存在边界 bug
工具设计的不规范
描述简略、缺少使用边界说明和负面清单、参数缺乏具体示例
技术选型的滞后性
倾向使用训练数据中最常见但已过时的模型和 API
外部生态的脱节
使用废弃 API、不再维护的库或有缺陷的模式
提供高质量的 Agent 实现作为参考范例,引导代码生成 Agent 在此基础上修改，而非从零开始
Agent 接到开发新 Agent 的任务时，应首先复制自己的代码,然后针对性修改：调整系统提示词匹配新角色，替换或增删工具适应新功能，修改业务逻辑但保留架构框架
这种“自我复制并适应性修改”的模式，既保证新 Agent 继承核心技术优势，又允许在特定维度上差异化
<br>
交互：观察与动作空间的扩展
模态与触发时机的扩展
模态决定观察和动作的形式
触发时机决定观察和动作的节奏
观察空间的扩展
内容
上下文工程、记忆与知识库
模态
语音、屏幕、物理传感器
时机
世界主动推送、连续流
动作空间的扩展
内容
工具、代码生成
模态
说话、点击、关节运动
时机
跨回合、可打断、可抢占<br>
回合制是模型与接口的一种交互约定，不是环境的性质
异步与事件驱动：当世界主动找上门
核心能力
异步执行是常态
许多任务需要长时间运行，不应阻塞用户交互
事件优先级的动态判断
Agent 需要智能地选择处理策略
取消当前操作（紧急）
加入队列（常规）
还是并行处理（独立的轻量级查询）
中断和恢复的流畅性
被打断的对话或任务应该能够自然恢复
事件驱动的异步 Agent 架构
所有的输入、输出、思考过程和外部交互都被统一建模为事件流
<br>
OpenClaw 的事件驱动机制实现
Hooks（事件钩子）
响应 Agent 生命周期中的事件，如会话创建、重置等
Cron（定时调度器）
按 cron 表达式,执行周期性任务
Heartbeat（心跳守护进程）
每隔 N 分钟唤醒一次 Agent，检查是否有需要关注的事项
PineClaw的Channel 机制
建立实时的事件通道
Agent 框架的核心价值
真正的 “主动服务” 不仅需要 Agent 能定时检查事件，更需要事件能主动通知 Agent
将所有输入建模为事件流，通过事件循环驱动 Agent 的思考和行动，是实现这一目标的架构基础
事件触发工具
定时器（set_timer）
处理依赖物理时间的事件
后台任务监控（monitor_shell）
处理来自异步执行的工具或命令行任务的事件
外部事件通道（connect_channel）
把新邮件到达、API 回调、IM 消息等外部事件实时推送给 Agent
在设计层面
事件触发工具应定义清晰的触发条件和过滤规则，避免无关事件唤醒 Agent 浪费算力
事件载荷（payload）应包含足够的上下文信息，减少 Agent 被唤醒后还需要额外查询的次数
用户沟通工具
多渠道的用户沟通与召回
Agent 的响应不应局限于单一渠道，通知机制同时也是用户召回机制
消息发送扩展到即时通讯、短信、邮件、电话、推送等多种渠道
Agent 根据紧急程度、用户状态、内容性质、用户偏好综合决定渠道的选择
既保证不错过重要的消息，又避免重复打扰
对于长时间运行的任务，Agent 需要在完成时主动通知用户，召回用户的注意力
对于定期性的任务（如每日总结、周报），通知可以帮助用户建立固定的交互习惯
虚拟身份与隔离执行环境
虚拟身份需要部署在隔离的执行环境中
虚拟电脑（VM/容器）和虚拟手机（Android 模拟器）为 Agent 提供操作系统级的隔离和完整的桌面/移动操作能力
独立身份挑战
反机器人机制
数据中心 IP 的虚拟环境很容易被识别
往往需要配置住宅代理网络（使用真实家庭 IP）才能正常访问
访问用户真实账号的场景
认证后的会话令牌可以在有效期内复用
在自主性与安全性之间取得平衡
Agent 与虚拟环境之间的数据交换通过共享文件系统完成
各方之间传递的始终只是轻量级的路径字符串
事件处理机制
处理策略
事件的结构化建模
输入都建模为包含丰富语义的结构化事件
来源
渠道
内容
上下文
基于紧急度的动态处理策略
取消式处理（Cancellation-Based）
用于紧急事件，其本质是为紧急事件提前制造一个安全点
主动中断当前步骤，把这一刻变成可以消费新事件的边界
队列式处理（Queued）
用于常规事件。当非紧急事件到达
并行处理（Parallel）
用于独立的轻量级查询
与主任务无关、需要快速响应、执行成本低
紧急度的判定
紧急事件：用户中断（user.interrupt）、监督指令（supervisor.instruction）、Agent 间中断（agent.interrupt）、标记为紧急的外部触发器
非紧急事件：常规用户输入（user.input）、Agent 输入（agent.input）、工具结果（tool.result）、定时器触发（timer.trigger）、常规外部触发器。
不支持原生异步时的兼容方案
兼容同步格式的异步实现
在没有打断发生的常态下，让 LLM 看到标准的同步轨迹，只在打断时才插入占位符来修复格式
五条关键规则
及时记录 API 已完成的 assistant 消息和工具调用项
工具调用完成时才记录 tool result
工具执行中的打断需要占位符
在没有原生 steering 或受支持的中途续接接口时，取消未完成的生成，保留已经确认完成的消息和工具状态，将新事件追加后重新请求
非打断事件进入队列等待批处理
通过任务句柄表达异步语义
从工具接口的设计层面明确异步语义
关键在于工具的名称和描述本身就要传达异步的语义
队列式处理中的注意力分散问题
提示词层面：告知模型 “当收到多个连续事件时，请确保全面考虑所有信息”
Agent 状态栏标记：在每个事件前添加显式标记
模型原生异步：GPT-6 Astra
<br>
异步工具调用将“发起行动”和“获得结果”分开
回合中途引导让用户可以在任务进行中修正方向
从“能接收异步消息”到“可靠处理异步任务”
检查三件事
结果归属与未完成状态
任务恢复与动作控制
多条更新的综合使用
可以通过异步环境中的训练改进模型，也可以通过清晰的任务状态、事件来源和执行反馈改进系统
语音：最自然的人机接口
范式一 · 级联流水线（Cascading）
VAD 语音活动检测
判断是否说完
ASR 语音识别
音频转文字
LLM
理解、思考、生成
TTS
文字转语音
从串行到流式感知
串行
延迟累积
须等待一段静音才能确认说完
信息丢失
有声/无声二值信号无法表达犹豫、情绪、附和和环境声
上下文被切断
邮箱、人名和专有名词可能被分片识别而出错
流式感知
ASR 边听边转
LLM 推测执行
LLM 分段输出
TTS 增量合成
范式二 · 端到端全模态模型（Omni）
<br>
Omni 模型可以理解声音中的停顿和
Omni 模型仍然假设轮流说话，通常要靠 VAD 划分发言权
范式三 · 全双工交互模型
交互模型
交互性不再依靠 VAD 等外部 harness 拼装实现，而是内建在模型中。其微轮次机制以短音频块持续推进，让静音、重叠和打断都作为连续上下文保留
交互模型还可以把完整对话委派给后台推理模型，自己继续维持话头；后台结果返回后，前台再在合适时机接入
认知时序：实时交互与深度思考
快思考回应，慢思考回答
快思考可以在几百毫秒内先给出即时回应
慢思考则在后台完成更深的推导
快思考交互，慢思考提醒
让后台模型通过状态栏或专门接口向前台模型提供建议
前台继续维持话头并决定如何表达
端到端思考与表达统一
模态锚定思考蒸馏（MGRD） 让模型基于声学特征思考,让模型基于声学特征思考
MPS 双脑架构让构思与表达并行
快慢思考分离与端到端思考的取舍
慢分离并不只是对延迟的妥协，也是一种让交互能力与智能上限分别演进的模块化选择
更像人的语音合成
THINKING、EMO:happy 和 SPEED:0.8x，由 TTS 将它们映射为停顿、韵律、语速或笑声、叹气等非语言音频
Computer Use：GUI 自动化 Agent
Computer Use（也称 GUI 自动化 Agent）让 AI 像人类一样通过观察屏幕、操作鼠标键盘来使用软件
核心是一个感知-思考-行动的循环
Agent 截取当前屏幕画面
多模态模型接收截图和任务指令
执行层在真实环境中执行该动作
等待界面响应后再次截图，进入下一轮循环<br>
动作空间
GUI 操作工具（computer tool）
命令执行工具
文件编辑工具
视觉定位
Set-of-Mark：视觉标注法
图像分割模型（SAM、SEEM 等）在截图上自动切出候选区域
为每个区域叠加编号标记
模型看到的是一张带编号的图
只需报出编号，由系统换算成对应区域的中心坐标
结构化元素索引：SoM 思想在 Web 上的结构化实现
通过浏览器调试接口（CDP，Chrome DevTools Protocol）获取网页的结构化表示（DOM 树）和无障碍信息
自动检测哪些元素可以交互（按钮、输入框、链接等）
为每个可交互元素标注唯一 ID 并在截图上绘制边界框
同时生成文本列表描述每个 ID 对应的元素
纯坐标预测
在海量 GUI 截图和元素位置的配对数据上训练视觉模型
让它学会将自然语言描述（如“点击提交按钮”）直接映射到截图中的精确坐标
Computer Use 的世界模型
世界模型让 Agent 能够在行动前预测桌面接下来可能变成什么，从而实现这种类似于人类的 “推测执行” 机制，大大提高效率
一个可用于 Computer Use 的世界模型至少要能编码当前状态、预测候选动作造成的状态变化，并把预测交给规划器决定下一步
Agent 就能在真正点击之前比较候选动作的后果，在页面加载期间准备下一步，并在弹窗一闪而过时根据状态差异恢复
移动端：生态壁垒比技术更难
传统互联网应用的核心变现逻辑是流量与注意力：用户刷信息流时看到广告，搜索商品时跟随推荐算法的引导，浏览页面时产生冲动消费
AI 不会关注广告，也不会冲动消费，直奔目标完成任务就走。对于靠广告和流量变现的平台来说，Agent 的每一次操作都在侵蚀其商业模式的根基
Agent 的评估
评估指标：成功的定义
技术奇观：用 Pass@k 看能力上限
“奇观” 是指在大量尝试、充足时间和人工筛选下展示出的能力上限
在同一任务上运行k次，只要至少有一次通过，任务就算通过
Best@k
输出是连续得分，则取最好的一次，记为 Best@k
业务可靠性：关注 Pass^k
同一任务连续运行k次，要求每一次都通过，且不能触发安全、合规或幻觉等一票否决项
评估环境
五个组成要素
数据集（Dataset）
环境状态（Environment State）
工具接口（Tools）
评分标准（Rubric）
执行协议（Interaction Protocol）
人机交互型与工具调用型评估环境
SingleTurnEnv
单轮问答、数学题
ToolEnv
搜索+信息综合
StatefulToolEnv
修改数据库记录
SandboxEnv
代码执行与测试
子主题
评估数据集的设计
基准设计的横向对照
τ²-bench
客服场景下的人机交互和工具调用
SWE-bench Verified
软件开发，coding
AndroidWorld
操作 Android 手机 GUI
OSWorld
操作 Linux 桌面 GUI
Terminal-Bench
操作 Linux 终端，coding
GAIA
搜集信息的通用 AI 助手
验证器
SWE-bench Verified 将 “修复完成” 拆解为两个独立命题。
FAIL_TO_PASS 修复前失败、修复后通过
PASS_TO_PASS 修复前后均通过
OSWorld 的验证器能发现表面完成但实质错误的情形
它配备 134 个独立评估函数
拥有完整的操作系统访问权限
能够检查文件系统结构
进程状态
网络连接与应用内部状态
Terminal-Bench
在 start_kernel 中加入自定义 printk，生成 initramfs 并在 QEMU 中运行，成功标准是启动日志中出现该自定义消息
任务的难度划分
GAIA 全套 466 题分为三级难度
Level 1 只需一至两个工具
Level 2 需要多步思考
Level 3 需要复杂组合
τ²-bench 还专门设计了陷阱任务
数据泄漏防范
GAIA 使答案无法从互联网直接检索
AndroidWorld 以单个模板派生大量实例,每次评估随机生成参数值
Terminal-Bench 在题面中嵌入金丝雀标识符,每道题携带一个 canary GUID，若模型能够输出含该 GUID 的内容，即说明基准数据已进入训练集
质量控制与长期维护
任务指令过于笼统，导致答案可被猜测
成功条件不够精确，导致验证误判
用户模拟器行为过于机械
用户不仅参与对话，也参与操作
任务实例动态生成
SWE-bench Verified：发布前淘汰 71% 的原始任务
OSWorld：发布后 15 个月中暴露出 300 余个问题
评估集的三个来源
公开基准用于粗筛模型与借鉴设计手法
自建业务集覆盖真实的任务分布，可以作为模型选型、Harness 设计决策的依据
生产轨迹回流来自线上的真实失败用例
自动化评估方法
LLM-as-a-Judge
LLM-as-a-Judge：自动化评估的核心
<br>
Rubric（评分标准）：LLM 评判的依据
Rubric 四准则
基于专家指导
必须反映领域知识，捕捉核心事实和推理步骤
全面覆盖
涵盖事实准确性、逻辑连贯性、完整性、安全性，而且不仅定义正面标准，还要明确陷阱
按重要性加权
分为必要项（Essential）、重要项、可选项、陷阱项,支持一票否决机制（Veto）
评价标准自包含
每个评价项独立可操作，不依赖评价者的领域知识
同源模型问题与多源评判<br>
多模态 LLM-as-a-Judge
多源异构评判
TTS 评估（TTS 即 Text-to-Speech，文本转语音）
ASR 评估（ASR 即 Automatic Speech Recognition，语音识别）
UI 评估：采用第一章命名的提议者—审核者模式
视频剪辑评估：通过关键帧验证剪辑起止点和特效应用是否正确
失败归因：从整条轨迹定位首个错误
归因标注 Agent 可以利用 LLM 规模化完成大量生产轨迹的根因分析
归因记录需要结构化，可以采用 JSON 或 YAML 文档格式，并引用具体的步骤号、工具名和观察证据
区分根因与后果、判断是否可恢复并给出置信度
在保存归因记录时，除了 LLM 输出的记录，还应把任务目标、环境状态、Agent 版本、工具集版本和完整的 Agent 轨迹一起保存，以便进行回归测试
端到端回归任务与轨迹前缀回归任务
端到端回归任务
端到端回归任务从初始状态和用户请求开始，让 Agent 完成整个任务，并检查最终状态、必要输出和安全条件
轨迹前缀回归任务
已有的上下文、对话、工具返回和环境状态冻结下来，只要求 Agent 思考并执行下一步或下几步可观察动作，成本更低，也能隔离单个策略或工具问题
构建轨迹前缀回归任务集往往比端到端回归任务集更重要
失败归因完成后，就可以构造包括端到端和轨迹前缀回归任务在内的评估数据集
位置偏差（Position Bias）
标准的缓解方法是交换顺序各评一次取平均
评估驱动的模型选型
选型的关键维度
吞吐与延迟指标
输入吞吐量 / 输出吞吐量
Prefill（预填充)
Decode（解码）的速度
TTFT
等于排队时间加上 Prefill 时间
思考延迟
不同模型生成的思考 token 数差异可达数倍
p95 尾部延迟
95% 的请求都不会超过的延迟
成本
输入/输出/缓存 token 的定价
性能
Pass@1(单次平均成功率)、Pass@k、Pass^k、Best@k 等指标
速率限制与可靠性
RPM（每分钟请求数）/ TPM（每分钟 token 数）
预算—能力曲线
固定预算下的单点成绩不足以判断 Agent 能否胜任长程任务
最佳 Agent 得分约为人类专家的 4 倍
异构的模型组合需要通过评估来验证，确认整体效益是否超过了所增加的系统复杂度，以及是否会在一些场景下出现性能回退
模型的行为策略
面对同一个代码任务，有的模型会先广泛探索仓库再修改；有的模型则凭较少的局部证据快速定位，先改再用测试反馈补齐认识
Agent 系统的成本分析
成本的构成要素
模型推理成本是最直接的部分
工具调用成本
外部 API 费用
代码执行的沙盒资源
工具返回结果注入上下文后产生的 token 费用
基础设施成本
运维开销
成本优化策略
复用 KV Cache
压缩上下文
分层选择模型
异步批处理
波谷分批处理
成本监控与预算控制
按任务类型、模型、用户等维度追踪 token 消耗和 API 费用
每个任务的成本上限
评估驱动的持续迭代
在自己的评估数据集上运行新模型，对比任务成功率、工具调用正确率、延迟和成本
精细化的数据驱动决策
评估结果的统计显著性
配对分析
两组共享任务与随机条件，而不是分别抽两批样本再比较平均值
多重比较
收紧显著性阈值，或对正向结果做独立复跑
分差要超过噪声、在配对分析中成立，并且能够复现，才值得据此切换模型或发布改动
Agent 的可观测性
可观测性的价值
问题诊断
完整的轨迹让开发者能回放全过程，而非靠猜测
持续优化的基础
成本管理
案例累计
数据基础是追踪（Trace）
OpenTelemetry 是通用的分布式追踪标准
同一份追踪数据可以对接不同的分析后端，避免被单一平台锁定
支持 A/B 测试
回流并转化为评估资产
从外部评估到内部评估：生产级 Agent 的评估基础设施
消融基础设施
每个主要特性都应是可独立关闭的，团队应定期验证每个特性的实际贡献
AB 测试方法论
多臂而非二元
设计多个渐进式变体
区分机制指标和目标指标
设置护栏指标
记录基线统计
双层特性开关系统
编译时开关
运行时开关
提示词敏感性评估
系统提示应该能够确定性地渲染
建立提示词的版本化快照机制
每次提示词变更都应在评估集上运行回归测试
以隐私感知分析为评估基础
从一开始就把隐私约束设计进去，而非事后加装
多 Agent 协作
多 Agent 协作的分类框架
维度一：上下文是否共享
共享上下文
后续 Agent 接收前一个 Agent 的完整对话历史和轨迹
优势在于信息不丢失，每个 Agent 都能回顾之前任何阶段的细节；挑战在于上下文可能快速膨胀
不共享上下文
每个 Agent 维护完全独立的上下文和对话历史
模块化和隔离性更好，每个 Agent 只需关注与自身职责相关的信息
系统也更易扩展和维护——增加新 Agent 不需要改动现有 Agent 的内部逻辑，只需定义好接口和数据格式
Agent 间的通信机制
工具调用的参数
把下游 Agent 封装成工具，上游 Agent 把结构化数据通过工具参数传给下游 Agent，适合需要类型确定、结构清晰的场景
共享文件系统
Agent 之间通过读写共享目录下的文档、代码等中间产物来交换信息，适合产物较大或需要持久化的场景
消息总线（Message Bus）
一个专门负责在 Agent 之间传递消息的中转站，Agent 不直接调用彼此，而是把消息发送到消息总线，由它转发给目标 Agent
维度二：协作拓扑
对等协作模式（Peer Collaboration Pattern）
少量 Agent 按照固定的拓扑形成迭代改进循环
管理者模式Orchestration Pattern）
一个中心化的 Manager Agent 负责任务规划和调度，多个子 Agent 各负责特定子任务
去中心化模式（Decentralized Pattern）
没有运行时的中心控制者，Agent 之间像人类一样互相沟通，协作完成任务
多 Agent 何时真正优于单 Agent
同一模型自我审查
通常无效甚至有害
不同 Agent 辩论同一段文本
在等计算量下与单 Agent 持平
审核者使用测试执行结果审查代码
显著提升
审核者查看渲染截图审查前端/PPT 代码
显著提升
审核者使用外部工具验证事实
显著提升
共享上下文的多 Agent 协作
transfer_to_agent
替换当前 system prompt，并通常替换工具集
只暴露当前角色工具
每次切换都改变请求前缀；从变化点起的前缀缓存通常无法复用
约束能力强：越界工具可在 schema 层不可见
Skill
固定 system prompt 中的 Skill 目录，按需把 SKILL.md 追加到轨迹
通常固定暴露工具全集，或使用稳定的工具搜索入口
静态前缀保持不变；Skill 内容成为末尾轨迹，已有前缀可继续复用
约束能力弱：Skill 是行为指令，硬权限仍需 Harness 门
角色差异主要来自知识、流程和写作风格时，优先使用 Skill
角色差异涉及权限、工具隔离、合规边界或需要在运行时强制禁止某类动作时，使用独立 Agent 或 transfer_to_agent 工具，并在 Harness 层通过代码限制工具调用
不共享上下文的多 Agent 协作
每个 Agent 都是独立的实体，拥有自己的上下文、轨迹和状态
多Agent 眼中的文件系统(产物交换的问题)
Agent 专属工作区（Scratchpad）
避免多个 Agent 的临时文件相互覆盖，以及保持主 Agent 上下文的精简
子 Agent 的试错过程留存于自身工作区，仅将最终产物提交至共享空间
多 Agent 共享空间（Shared Workspace）
多个 Agent 共同读写、且用户可见的协作区域，是不共享上下文架构下 Agent 间交换产物的主要媒介
乐观锁、工作副本隔离
外部挂载资源（Mounted External Resources）
通过适配器（adapter）映射为文件系统中的挂载点
访问受外部权限约束
延迟更高且一致性更弱
以按需只读为主
统一的文件接口使 Agent 无需为每个数据源定制专用工具，但也掩盖了上述性能与安全差异，因此需在挂载层面显式管理只读/可写、超时与凭证边界
系统内置资源（Built-in System Resources）
系统预置、对所有 Agent 只读共享的资源包
该层全局共享、只读、跨会话稳定，可被所有 Agent 并发读取而无需并发控制
Agent 间的通信与控制 (控制平面)
消息传递
消息总线
Agent 将消息发布至总线，由总线按订阅关系转发，发送方无需知晓消费者
状态查询
用消息传递获取状态
主动获取
消息总线状态更新或主动汇报
用共享文件系统获取状态
最彻底的形态是轨迹持久化
约定进度文件
检测卡住状态
执行终止
优雅终止
主 Agent 发出 terminate 信号
子 Agent 在当前步骤的安全点响应
先清理资源，返回确认（ack）后退出
强制终止
直接终止进程
资源与调度
启动子 Agent 时设定步数或 token 预算，超限即止
困难任务交给强模型，机械任务交给低成本模型
并发数设置上限
当并发数达到上限，更紧急的任务到来时，打断执行中的子 Agent
对等协作模式：相互制衡与迭代改进
Loop 工程
常见类失败
过早终止
偷懒式假完成
过早放弃
假成功
验证最有效的组织方式
提议者-审核者范式
辩论模式
头脑风暴模式
多个 Agent 独立生成创意，然后相互分享、彼此启发
专家小组模式
多个 Agent 各自代表一个专业领域的视角，共同讨论跨学科问题
管理者模式：中心化协调
模式定义
先理解整体任务，再拆解为可分配的子任务，选择合适的 Agent 去执行，跟踪进度并处理异常;最后把各 Agent 的输出整合为最终结果;应当将最强的模型和最精心设计的提示词分配给 Manager（规划者），而不是将资源平均分配给所有 Agent
顺序协调形态
Manager 按顺序依次调用专门 Agent，每个 Agent 完成后返回结果，Manager 再决定下一步
并行协调形态
当多个子任务可以并行执行
消息总线（Message Bus）作为基础设施
Manager Agent 不仅要规划并行任务，还要实时监控所有运行中的 Agent，协调通信，在 Agent 成功或失败时做出全局决策
管理者 Agent 生成 Agent 工作流
管理者先把 Agent 工作流写成一段代码，再交给确定性的运行时去执行
去中心化模式
管理者 Agent 崩溃往往会成为系统最大的单点故障
编排（orchestration）与编舞（choreography）
前者由指挥统一调度，后者靠每位舞者自行把握入场时机
把 SOP 编码进多 Agent 系统，让每个角色像流水线上的专业工种一样产出标准化交付物，交付物天然构成了角色间的通信接口
移交包
任务描述（接收方要做什么、验收标准是什么）
已确认的事实与约束（用户偏好、业务规则、前序阶段敲定的决策）
结构化产物的引用（文件路径而非文件内容，接收方按需读取）
每个 Agent 不需要理解其他 Agent 的 “思考过程”，只需要理解移交包和产物的格式与语义
跨组织协作：A2A 协议
Agent Card
一份描述 Agent 能力的元数据文档
任务生命周期管理
A2A 把协作单元建模为任务（Task），带有明确的状态机（已提交、进行中、需要输入、已完成、失败），原生支持长时间运行的任务和流式进度更新
不透明协作
Agent 之间只交换任务与产物（Artifact），不暴露内部的提示词、思考过程和工具实现
多 Agent 协作的失败模式
失败模式一：共享文件系统的并发冲突
简单冲突（文件级写入冲突）
语义冲突（逻辑级一致性冲突）
乐观锁（Optimistic Locking）机制
乐观锁只能防止同一文件的写入冲突
工作副本隔离
各自在自己的副本上并行修改
冲突被集中推迟到最后的合并点
失败模式二：错误的级联放大
进程间传递字节，逐位保真，但 Agent 间传递语义，每转述一次都是有损的重新编码
交叉验证是打断这条链的关键手段
看原始证据和最终结论是否一致
失败模式三：同质趋同
错误不一定沿通信链传播，也可能由多个同质 Agent 独立地产生
系统除了要有意识地引入模型、上下文和数据来源的差异，还应使用命名空间、资源配额和速率限制，防止相同决策同时冲击共享资源。
失败模式四：互相扯皮
目标互斥时，系统还可能从趋同走向对抗
运行时必须预先定义目标优先级、资源所有权和权限边界，并在冲突无法按可验证规则解决时暂停执行、交由人工裁决
失败模式五：循环失控
失控的 Agent 有时会生成数千个子 Agent，浪费大量 token
对于自主性较强的 Agent，建议使用独立的 API key，防止 token 开销不受控增长
失败模式六：理解债与认知投降
随着 Agent 的智力提升、执行长流程任务的能力提升，人是否能理解 Agent 的交付件，是否能给 Agent 有效的指导，变得越来越难
认知投降，工程师习惯了用 Agent 代劳，逐渐放弃独立思考与审查，导致软件质量失控
模型后训练
从预训练到 RL
四段全景
预训练
数据集
海量原始互联网文本
优化目标
预测下一个词
学习结果
语言规律、世界知识、基本推理
典型代价
极高（数百万～数千万美元）
Mid-training
数据集
目标语言/领域/能力语料与保留数据
优化目标
继续预测下一个词（通常对全部 token 计算损失）
学习结果
补齐领域知识、语言和基础能力
典型代价
中到高，取决于 token 规模与是否全参训练
SFT
数据集
几千～几万条“输入—输出”示范对
优化目标
预测下一个词（只在回答上算损失）
学习结果
指令遵循、输出格式、风格、流程协议
典型代价
低（几小时～几天）
RL
数据集
任务、环境 + 奖励信号（参考答案可选）
优化目标
最大化期望奖励
学习结果
可迁移的决策策略、探索出的新解法
典型代价
高（常是 SFT 的几十～上百倍）
预训练在做什么：预测下一个词
给模型看一段文本的前半部分，让它猜下一个 token 是什么
模型每猜一次，就把自己的预测和真实的下一个 token 比较，差距（称为损失 Loss）越大，就越用力地调整参数，让下次在类似上下文里猜得更准
在几万亿 token 的互联网文本上反复做这件事，模型被迫学会了语法、事实、逻辑乃至基本推理
Mid-training 的本质：在目标分布上继续学习
沿用预训练的下一个 token 目标，但把数据分布收窄到目标领域，并混入一部分通用保留数据以控制遗忘
SFT 的本质：换了数据的“预测下一个词”
SFT 在数学上和预训练是同一个任务
SFT 与预训练的差别
数据不同
预训练用原始互联网文本
SFT 用人工精心准备的“输入—输出”对
损失只算在“回答”上（loss masking，损失屏蔽）
一条 SFT 样本包含问题和标注回答两部分
优化目标是让标注回答里每一个 token 的概率尽可能高，也就是尽量复现示范
对目标明确、格式固定的任务，这种方法极其高效
用极高的样本效率，把一套稳定的“输入→输出”映射与协议固化进参数
它固化的是“格式、风格、流程”这类协议性知识（该怎么说、怎么做），而非大量事实性知识（知道什么）
什么时候需要先补底座，再做 SFT/RL
格式支持
SFT 用少量示范稳定格式与基本流程
能力支持
缺领域语言、事实、代码模式或长上下文基础能力，优先用 Mid-training 补底座
已有能力但不会按接口表达，先用 SFT
RL 擅长把已有但概率较低的成功行为推高
SFT 与 RL 的本质区别
SFT 最大化标注回答的概率
RL 最大化期望奖励
从经典 RL Agent 到现代 Agent
强化学习（Reinforcement Learning, RL）
核心在于学习如何根据当前情境选择动作，以获得最大的累积奖励（Cumulative Reward）
强化学习系统包含五个核心要素
动作空间
定义 Agent 可以采取的所有行动集合
策略
Agent 的行为准则，规定在给定状态下应该怎么做
奖励信号
Agent 的目标是最大化长期而非即时奖励
价值函数
估计从某个状态出发，未来总共能获得多少累积奖励，帮助 Agent 在没有即时反馈时做出明智决策
环境模型（可选）
预测环境对动作的响应
把思考 token 作为特殊动作纳入策略输出空间,内部思考成为学习到的语言动作空间的核心组成部分
Mid-training：补知识与基础能力
主要解决两类缺口
知识缺口
通用预训练没有充分覆盖目标语言、金融/医疗/法律领域、企业内部文档或某类代码库，模型连概念与术语都不能理解
基础能力缺口
目标任务要求基础模型尚未形成的长上下文、代码模式、数学推导或跨模态表征
Mid-training 数据如何构造
从失败分布反推数据
先按主题、语言、文档类型、代码模式与上下文长度切分评估，确认低 pass@k 来自哪类底座缺口；只针对知识和能力缺口补数据，避免把输出格式错误误诊成知识不足
构造高密度目标语料
原始文档适合建立术语和事实关联，代码仓库适合学习结构与依赖，教材式推导、合成释义和跨文档关联样本适合把隐含关系写得更明确
数据要做去重、质量过滤和评估集污染检查
按能力进行数据配比
数据需要包括书籍、长文档和代码仓库等自然长文本
体现长文本检索、多跳推理、指令遵循、信息聚合与统计等长文本原子能力的思维链数据
体现规划、工具选择与调用、长程状态跟踪和错误恢复等 Agent 必需能力的 Agent 执行轨迹
其中思维链和 Agent 执行轨迹数据可以从较强的开源模型蒸馏，也可以使用现有数据集
在每个阶段做“双重回放”
原始短文本和通用数据，用来保留语言、知识与短上下文能力
长度提升后的旧任务”：把模型已经会做的短任务放进当前长度的上下文，在不同位置加入相关信息和干扰项，检验同一能力在更长窗口中是否仍然成立
通用数据最好来自基模的原始预训练集；无法取得时，可以用 FineWeb-2 等开源预训练语料替代。
用多维门禁决定何时停止
除训练 loss 外，同时跟踪留出领域任务、通用能力、原有指令遵循和目标任务的 pass@1/pass@k
领域指标上升但通用保留集下降，说明混合或学习率过激
loss 下降而 pass@k 不动，则要检查数据是否真正覆盖所需能力，以及后续是否缺少访问知识的 SFT
SFT（监督微调）
核心价值
固化输出格式：把映射关系、交互格式、风格规范写入参数，使推理时无需冗长提示即可产出符合预期的输出
SFT 数据来源
人工专家示范
质量天花板最高，但贵且慢，适合用来定义格式与风格的 “种子数据”
教师模型生成
即合成数据，让强模型批量产出 “输入—输出” 对，过滤后再蒸馏给学生
拒绝采样
模型自己对同一问题采样多条候选，用验证器筛出正确样本再反过来训练自己
构造流程
先定义任务分布与输出 schema
再批量生成候选
然后用规则校验、格式检查加人工抽检做质量过滤
后去重、平衡配比、保证多样性
SFT 数据合成：从示范到可训练轨迹
少量人工种子、教师模型生成和验证器筛选组合起来
人工示范定义格式与边界，教师模型放大规模，规则验证或人工抽检守住质量
模型自举时，可以对同一题采样多条候选，只保留验证通过的轨迹，这就是拒绝采样微调（RFT）
合成数据的目标不是复述线上日志，而是从日志中提炼可复用的任务结构：用户意图、初始状态、可用工具、业务约束、常见失败方式和成功条件
线上数据 → 任务蓝图 → 合成任务 → 多次候选轨迹 → 任务验证与轨迹验证 → SFT 数据
开放式的沟通质量再由模型评价器补充，并用人工抽样校准。技能图、可执行环境和独立验证器可以进一步扩大任务覆盖并过滤无效轨迹
SFT 只保留验证通过的成功轨迹，学习稳定的格式、流程和基本动作
RL 让当前策略重新 rollout，利用环境奖励探索示范之外的路径
失败轨迹不应直接当作正确示范，可以用来构造偏好对、发现任务覆盖缺口，或补上诊断与修复后再加入训练
何时选择 Mid-training、SFT 与 RL
<br>
选择准则
领域概念、语言或基础操作不会；合理采样下 pass@k 仍接近 0
主要缺口
知识与能力不在基模的有效支持中
优先方法
Mid-training；动态事实则用 RAG
进入下一阶段的门槛
领域留出集改善，通用保留集可接受，目标任务开始出现可验证的正确或部分正确轨迹
偶尔能做对，但格式、工具 schema、语气或固定流程不稳定
主要缺口
行为协议没有固化
优先方法
SFT 或约束解码
进入下一阶段的门槛
解析成功率稳定，关键动作和输出协议可被验证器可靠评分
已有非零成功率和可靠奖励，但好策略概率低、长程决策或 OOD 泛化不足
主要缺口
概率质量分配与策略优化
优先方法
RL
进入下一阶段的门槛
奖励与真实目标一致；rollout 组内有足够奖励差异；独立测试集随训练改善
只有少量稳定示范，尚无可交互环境
主要缺口
可模仿数据有、在线反馈无
优先方法
SFT/RFT/离线偏好优化
进入下一阶段的门槛
先建立基线与评估，再判断是否值得建设 RL 环境
实际决策可以按以下顺序进行
先排除不需要改权重的方案
Prompt、工具、代码约束、上下文管理能解决行为问题时不必训练；事实需要频繁更新、引用或删除时优先 RAG
在目标留出集上测能力支持
不只看贪心的 pass@1，还要在固定采样配置下看 pass@k、部分进展率、格式解析率，并人工审计失败原因
若 pass@k 仍近零且失败集中在知识/基础能力，先做 Mid-training，重新评估后再决定后续步骤。
用 SFT 立协议，不拿它硬塞知识库
当模型“会做但不会按要求做”时，用高质量示范固化 JSON schema、工具调用、术语用法、流程和风格
少量事实可以随示范学入参数，但大量事实知识不应让少数 QA 对承担
只在有探索空间时上 RL
当前策略已经能产生可评分、偶尔成功的 rollout，奖励又能忠实反映部署目标时，RL 才适合把低概率成功策略推高
探索示范外路径。pass@k 近零时先补 Mid-training/SFT 或设计可达的课程与部分奖励；全零 rollout 上直接加 PPO/GRPO 通常只会消耗采样预算
后训练实践要点
要点集合
用 SFT 硬塞知识库，或把所有知识都交给参数
大量稳定领域知识与基础能力可以用 Mid-training 写入参数，SFT 再教模型如何访问和表达；
需要动态更新、引用、权限控制或删除的事实应由 RAG 管理
格式未稳定就引入 RL
如果模型不能稳定生成奖励计算所需的 JSON，训练信号会变得稀疏或失真
可接受的解析失败率取决于任务与奖励设计，不应把固定阈值当作普遍标准
先用小规模评估设定格式稳定性门槛，必要时通过 SFT 或约束解码稳定输出后再应用 RL
把标称窗口当成有效窗口
位置编码允许 128K 输入，不代表模型在 128K 上仍会检索、推理和规划
扩窗前应完成当前长度的能力门禁，每个阶段保留短数据和前序阶段 replay，并用“能力 × 长度”矩阵检查退化
pass@k 近零仍直接上 RL
全失败的 rollout 没有正向轨迹，GRPO 组内优势也会消失
先用 Mid-training 补能力、用 SFT/蒸馏扩大有效支持，或构造与最终目标一致且可达的课程和部分奖励
奖励函数设计不当导致奖励黑客
模型学会钻奖励的漏洞来获得高分，而非真正完成任务（比如只看回复长度就生成冗长无意义的文本）
应该评估最终目标而非中间指标
忽视仿真保真度
若仿真过于简化（客服总按固定模式回复）或环境响应不真实（错误信息与生产环境不一致），训练出的策略在真实场景中会完全失效
高保真仿真环境的构建成本可能高于训练本身
过度训练导致泛化下降
训练损失持续下降但验证集性能反而恶化时，模型正在死记训练细节
Mid-training 会造成通用能力遗忘，SFT 会过拟合示范，RL 过度优化也会让策略过拟合当前奖励与任务分布
三者都需要独立保留集和早停
价值函数崩溃与探索不足
PPO 中价值估计不准确会导致优势计算出现偏差，表现为训练曲线剧烈震荡
温度参数过低或随机性不足会使 Agent 陷入局部最优
把训练—推理数值失配当成小噪声
更新前 sampler/trainer 的概率比已经偏离 1
会把 on-policy 训练悄悄变成 off-policy
应监控 log probability 差异、近似 KL、裁剪比例和策略 staleness
低估 RL 的计算成本
SFT 上表现良好的任务转 RL 可能需要 10-100 倍训练时间
如果测试分布与训练高度一致，SFT 可能已经足够
训练数据质量低下
Mid-training 会吸收语料中的错误关联，SFT 会直接学习示范噪声，RL 的奖励若有系统性偏差则会把策略朝错误方向放大
核心原则
在投入大规模资源前，先用小规模实验验证关键假设
小批 Mid-training 语料检查知识/能力与遗忘曲线
少量 SFT 数据测试格式能否稳定
小批 rollout 检查 pass@k
奖励差异和 sampler/trainer 数值一致性
Collect
Get Started
Collect
Get Started
Collect
Get Started
Collect
Get Started
评论
0 条评论
下一页
