拆解 Agent 能力水位、验证闭环和知识库召回，说明工作记忆如何变成可复用工程资产。
导语
很多人用 Agent 的方式还停在"给它一个任务，等它吐出结果"。这个用法没错，但很快会撞到天花板：模型能写代码、查资料、改文档，也会在长链路里丢上下文、误判边界、重复踩坑。
真正拉开差距的不是某一次 prompt 写得多漂亮，而是能不能把使用过程沉淀成一套工程系统。这个系统至少要回答四个问题：怎么判断模型能力水位，怎么让任务链路可验证，怎么把经验变成可召回的记忆，怎么让 Agent 在下一次任务里少走弯路。
使用密度：能力边界不是想出来的
Agent 的能力边界很难靠少量试用判断。一天问一两个问题，得到的往往只是"能不能答"；高频使用后，才会慢慢看清它适合直接做什么，什么任务需要先拆，什么环节必须加验证，哪些流程值得沉淀成 skill、脚本或自动化。
更准确地说，高频使用是在训练人自己的任务建模能力。一个任务交给 Agent 前，至少要先判断五件事：
| 判断项 | 工程含义 |
|---|---|
| 是否能直接交付 | 目标清楚、输入完整、失败成本低，可以让 Agent 独立推进 |
| 是否需要拆解 | 任务跨度大，必须拆成调研、设计、实现、验证等阶段 |
| 是否需要验证 | 结果会影响代码、数据、发布、权限或对外表达，必须有检查点 |
| 是否不适合独立执行 | 涉及高风险操作、业务判断、权限边界或强主观取舍 |
| 是否值得沉淀 | 重复出现、有固定流程、有明确验收标准，适合做成 skill 或脚本 |
这里的重点不是"多烧 token"。重点是让模型在真实任务里反复暴露边界，再把失败、重试和复盘整理成可复用的流程。没有这个过程，所谓 Agent 能力评估很容易停留在主观体感。
Agent 价值函数：别只看模型聪不聪明
单一工程任务可以用六个维度粗略拆开：Coding 工程、可靠性/成本速度、长任务编排、工具使用、推理数学、多模态视觉。一个模型在 Coding 上很强，不代表它在长任务里稳定；一个模型回答很漂亮，也不代表它能承受真实工具链里的权限、文件、日志和验证。
如果进入复杂工程，评价方式还要再换一层。Agent 不是只"会不会做"，还要看它能不能少打扰人、能不能自己验证、产出能不能复用。
一个 Agent 如果任务完成率高，但每一步都要人盯，价值会被人工介入拖低；如果成本和等待时间太高，也会让"能做"变成"不值得做"。
能力水位：从协作到托付
复杂任务里的 Agent 可以按价值水位分层。这个分层比"某某模型第一名"更有用，因为它直接对应人该怎么用它。
| 水位区间 | Agent 特点 | 适合任务 | 人的角色 |
|---|---|---|---|
| 35-50：可协作 | 能按步骤推进边界清楚的任务，会读文件、改代码、跑验证，但长链路里容易漏细节 | 小需求、局部重构、文档整理、问题排查、低风险自动化 | 人像 reviewer，负责定义目标和检查关键路径 |
| 50-65：深度协作 | 能拆任务、调工具、反思失败并修正，能连续推进较长时间 | 多文件改动、调研报告、知识库整理、测试与修复循环 | 人负责边界、验收和风险控制 |
| 65-80：接近可托付 | 对常规任务有较强自驱和自验证能力，失败容易被日志、测试、review 捕捉 | 标准化需求、批量迁移、日常维护、低中风险工程任务 | 人主要设定目标和做最终验收 |
| 80-100：理想区 | 接近"有监督工作流节点"，能理解目标、维护上下文、调用记忆和工具，并控制成本 | 半自动项目交付、长期后台 Agent、跨系统工作流、团队知识资产运营 | 人负责价值判断、优先级和不可逆风险确认 |
现在的强模型已经能承担不少深度协作任务，但距离"多数复杂项目稳定托付"还有距离。更现实的路线不是等模型突然满分，而是在模型外侧补工程机制。
链路成功率：单步差一点，整体差很多
图：长链路任务需要用验证、反馈和重跑降低串联损耗
复杂工程任务最容易被低估的是串联损耗。假设一个项目有 N 个关键步骤，每步可靠率是 p，在没有验证和纠错前，链路成功率近似为：
p^N
这解释了一个常见现象：模型看起来每一步都"差不多对"，最后结果却不可用。因为长链路会放大每个小错误。
| 单步可靠率 | 10 步链路成功率 | 工程判断 |
|---|---|---|
| 70% | 约 2.8% | 看起来能答，实际不可用 |
| 85% | 约 19.7% | 开始可用，但必须依赖验证和重试 |
| 90% | 约 34.9% | 进入好用区，但仍不能裸奔 |
| 95% | 约 59.9% | 开始接近复杂项目可托付 |
如果任务扩展到 20 个关键步骤，95% 的单步可靠率也只剩约 35.8% 的链路成功率。这个数字很刺眼，但它正是长任务工程化的起点：不要迷信一次生成，要把验证、反馈、重跑、人工确认变成流程的一部分。
外侧机制：把模型变成可控工作流
模型能力不够稳定时，可以在外侧补四类机制。
| 机制 | 解决的问题 | 典型做法 |
|---|---|---|
| Harness + 反馈 | 提高单步准确率 | 用脚本、测试、静态检查、日志和人工 review 定位失败环节，再让 Agent 修正 |
| Loop 机制 | 让 Agent 主动发现问题 | 任务执行后自动检查结果，不通过就回到上一阶段重跑 |
| 记忆与知识库 | 减少重复解释和从零推理 | 把项目规则、历史决策、失败经验、偏好和资料索引做成可召回资产 |
| 赛马机制 | 用成本换质量 | 同一任务多模型、多窗口或多策略并行，挑选更可靠结果 |
这四类机制里，记忆与知识库最容易被低估。因为它不直接让模型"更聪明"，但会减少模型每次处理复杂问题时的搜索空间。上下文给得准，任务就短；任务变短，链路成功率自然上升。
语言生成不是理解，但可以利用它
人和大模型不是同一种东西。人有身体、动机、现实经验和长期目标；模型主要从数据和反馈里学习模式。这个差异不能抹掉。
但从"如何处理语言"看，两者有可借鉴的地方。人学语言并不是先拿语法书，而是在大量输入里捕捉统计规律，再慢慢形成结构。大模型预训练也是类似路线：在海量 token 序列中学习概率关系、长程依赖和上下文结构。
在复杂任务里，这个类比有一个实用结论：不要只让模型直接给答案，要让它维护一份可检查的工作状态。目标、证据、假设、风险、验证、下一步，这些东西都应该被语言化、结构化、可回看。模型最擅长处理文本状态，那就把任务状态变成它能处理的形式。
工作记忆：Agent 需要的不是聊天记录
图：工作记忆把历史经验压缩成下一次任务可召回的知识资产
"记忆"不是把所有聊天记录塞回上下文，也不是重新训练模型。更接近的说法是：Agent 给未来的自己写工作笔记。
一个可用的记忆机制通常有四步：
| 步骤 | 发生了什么 |
|---|---|
| 捕获 | 从历史对话、用户纠正、项目工作、失败经验里发现值得保留的信息 |
| 提炼 | 不保存完整记录，而是压缩成偏好、规则、坑点、流程、项目惯例 |
| 存储 | 写到本机 memory 文件、项目目录或知识库里，保留来源线索 |
| 召回 | 新任务开始或执行中，只把相关的少量记忆带回上下文 |
这里最怕两种极端：一种是完全不记，导致每次从零开始；另一种是全量记，把历史噪声都灌给模型。真正有价值的记忆应该短、准、稳定、可验证，能改变下一次行动。
Codex 与 Claude：同一思路的不同实现
不同 Agent 的记忆机制形式不同，但底层思路很接近：从历史任务里提炼经验，存成本地可读文件，再在相关任务里召回。
| 对比维度 | Codex 类机制 | Claude 类机制 |
|---|---|---|
| 触发方式 | 更偏后台自动从历史会话里提炼 | 更偏在项目执行中主动整理 |
| 组织形态 | 独立经验卡片，偏跨任务通用 | 目录页加专题文件，偏项目级组织 |
| 存储位置 | 统一记忆目录，方便跨会话使用 | 跟项目绑定，方便承接项目规则 |
| 共同点 | 都记"经验"而不是完整聊天；都能被人查看、修改、删除；召回时都强调少而精 | 共同点相同 |
这类机制已经很有用，但它也有明显上限。Agent 只能记住自己参与过的窗口和能访问的目录。真实工作环境里的飞书消息、会议纪要、文档、代码评审、设计稿、邮件和内部系统，往往都不在它的视野里。
还有一个问题：记忆通常跟着工具走。换一个 Agent，历史经验不一定能带过去。于是，一个更稳的方向是把个人或团队的知识系统独立出来，让不同 Agent 都能读取同一套可治理的知识资产。
知识库架构：从原始材料到可召回资产
个人工作记忆不能只靠"保存资料"。原始数据太乱，直接塞进知识库会出现一个尴尬结果：模型知道有这批资料，但召回不到关键片段。
更合理的链路是先清洗、分片、建卡，再进入语义学习和召回系统：
图：从原始材料到 Agent 召回的工作记忆沉淀链路
这个图里的关键点不是向量库，而是"结构化卡片"。真实工作里的召回维度经常是人、日期、项目、模块、MR、会议结论、待办、决策。如果这些维度没有在数据进入知识库前显式建出来，后面只靠语义搜索很难稳定命中。
五类知识：不是所有东西都该进记忆
一套可用的 Agent 知识系统，至少要区分五类内容：
| 类型 | 例子 | 建议存法 |
|---|---|---|
| 原始数据 | 聊天记录、会议纪要、MR、日志、文档、截图 | resource，保留来源和时间 |
| 可检索卡片 | 某次会议结论、某个 bug 排查、某个模块决策 | retrieval card，结构化摘要 |
| 长期记忆 | 稳定偏好、项目惯例、历史决策、常见坑 | memory，短、准、有证据 |
| 技能流程 | review 流程、日报生成、发布检查、排障手册 | skill / playbook / template |
| 实时状态 | 今日排期、线上指标、最新 MR 状态 | 不进长期记忆，现场查询 |
这张表背后有一个原则：长期记忆只放未来会反复用、能改变行动的东西。临时状态不该进长期记忆，敏感信息也不该进。否则记忆会从资产变成污染源。
记忆准入：短、稳、可回查
一条记忆是否值得保存，可以用五个条件过滤：
| 条件 | 含义 |
|---|---|
| 稳定 | 未来还会反复用，不是一次性状态 |
| 可执行 | 能改变下一次任务的做法 |
| 可验证 | 能回到原始证据，而不是凭空总结 |
| 不敏感 | 不包含 token、cookie、个人隐私和不该长期保存的信息 |
| 不空泛 | 不能是"认真验证""注意质量"这种废话 |
Skill 或自动化也有类似准入标准：重复出现、有明确输入、有固定步骤、有验证标准、有常见失败，才值得封装。否则写出来也不会被用，甚至会误导 Agent 走错流程。
召回策略：少而精比全量更重要
很多知识库项目最后失败，不是因为资料太少，而是召回太粗。Agent 每次拿到一堆无关上下文，会更慢、更贵，也更容易被干扰。
召回应按任务重排，而不是按"相似度最高"一把梭。一个更可靠的排序方式通常会综合四类信号：
| 信号 | 用途 |
|---|---|
| 项目相关性 | 当前任务属于哪个项目、模块或业务域 |
| 时间新鲜度 | 最近决策、最新接口、最新规范优先 |
| 证据强度 | 有来源、有会议结论、有代码或文档支撑的内容优先 |
| 可执行性 | 能直接改变下一步操作的记忆优先 |
这样召回出来的上下文才像"工作记忆"，而不是资料大杂烩。
从使用 Agent 到构建个人智能体
高频使用 Agent 和打造有工作记忆的个人智能体，其实是同一条路的两个阶段。
前一个阶段解决"我怎么摸清 AI 的边界"。通过大量真实任务，理解哪些事能交给它，哪些事要拆，哪些事必须验证。后一个阶段解决"AI 怎么记住我的边界"。通过记忆、知识库、skill、自动化和反馈，把个人经验变成模型能调用的外部系统。
这件事短期看是在提效，长期看是在改变个人工作方式。人的经验不只存在文档里，也存在聊天、会议、代码、复盘和脑子里的隐性判断里。把这些经验用正确粒度沉淀下来，Agent 才可能从"会回答的工具"变成"能承接工作上下文的协作者"。
结语
Agent 工程化的核心不是把模型神化，而是承认它的边界，然后用系统补齐边界。模型负责生成、推理和执行；Harness 负责验证；Loop 负责持续修正；知识库负责提供背景；记忆负责减少重复犯错。
如果只追新模型，每次升级都会兴奋一阵，然后重新遇到长链路失败。真正能复利的是另一件事：把每次失败、每次修正、每次判断，都沉淀成下一次 Agent 能读懂的工作记忆。