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、跨系统工作流、团队知识资产运营 人负责价值判断、优先级和不可逆风险确认现在的强模型已经能承担不少深度协作任务但距离“多数复杂项目稳定托付”还有距离。更现实的路线不是等模型突然满分而是在模型外侧补工程机制。链路成功率单步差一点整体差很多inline-02-validation-loop.jpg图长链路任务需要用验证、反馈和重跑降低串联损耗复杂工程任务最容易被低估的是串联损耗。假设一个项目有 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 需要的不是聊天记录inline-03-memory-knowledge-base.jpg图工作记忆把历史经验压缩成下一次任务可召回的知识资产“记忆”不是把所有聊天记录塞回上下文也不是重新训练模型。更接近的说法是Agent 给未来的自己写工作笔记。一个可用的记忆机制通常有四步步骤 发生了什么捕获 从历史对话、用户纠正、项目工作、失败经验里发现值得保留的信息提炼 不保存完整记录而是压缩成偏好、规则、坑点、流程、项目惯例存储 写到本机 memory 文件、项目目录或知识库里保留来源线索召回 新任务开始或执行中只把相关的少量记忆带回上下文这里最怕两种极端一种是完全不记导致每次从零开始另一种是全量记把历史噪声都灌给模型。真正有价值的记忆应该短、准、稳定、可验证能改变下一次行动。Codex 与 Claude同一思路的不同实现不同 Agent 的记忆机制形式不同但底层思路很接近从历史任务里提炼经验存成本地可读文件再在相关任务里召回。对比维度 Codex 类机制 Claude 类机制触发方式 更偏后台自动从历史会话里提炼 更偏在项目执行中主动整理组织形态 独立经验卡片偏跨任务通用 目录页加专题文件偏项目级组织存储位置 统一记忆目录方便跨会话使用 跟项目绑定方便承接项目规则共同点 都记“经验”而不是完整聊天都能被人查看、修改、删除召回时都强调少而精 共同点相同这类机制已经很有用但它也有明显上限。Agent 只能记住自己参与过的窗口和能访问的目录。真实工作环境里的飞书消息、会议纪要、文档、代码评审、设计稿、邮件和内部系统往往都不在它的视野里。还有一个问题记忆通常跟着工具走。换一个 Agent历史经验不一定能带过去。于是一个更稳的方向是把个人或团队的知识系统独立出来让不同 Agent 都能读取同一套可治理的知识资产。知识库架构从原始材料到可召回资产个人工作记忆不能只靠“保存资料”。原始数据太乱直接塞进知识库会出现一个尴尬结果模型知道有这批资料但召回不到关键片段。更合理的链路是先清洗、分片、建卡再进入语义学习和召回系统mermaid-01.png图从原始材料到 Agent 召回的工作记忆沉淀链路这个图里的关键点不是向量库而是“结构化卡片”。真实工作里的召回维度经常是人、日期、项目、模块、MR、会议结论、待办、决策。如果这些维度没有在数据进入知识库前显式建出来后面只靠语义搜索很难稳定命中。五类知识不是所有东西都该进记忆一套可用的 Agent 知识系统至少要区分五类内容类型 例子 建议存法原始数据 聊天记录、会议纪要、MR、日志、文档、截图 resource保留来源和时间可检索卡片 某次会议结论、某个 bug 排查、某个模块决策 retrieval card结构化摘要长期记忆 稳定偏好、项目惯例、历史决策、常见坑 memory短、准、有证据技能流程 review 流程、日报生成、发布检查、排障手册 skill / playbook / template实时状态 今日排期、线上指标、最新 MR 状态 不进长期记忆现场查询