agent错误捕获方法

每天一个大模型知识点，今天要讲的是，如果 a 证件调用了错误的工具，你该怎么处理？其实这个问题面试官不是在考你会不会写 try catch， 他 真正关心的是你有没有大规模工程化落地 agent 的 经验。为了让大家更好的学习大模型，我把完整的学习路线，还有以上各个阶段要用到的资料可以在主页置顶群里。大家好，我是彭宇。因为在现实场景里，大模型极其不稳定，幻觉格式错误、参数乱传简直是家常便饭。 如果你的 agent 稍微出点错，就直接当机，或者在那一本正经的胡说八道，那这个产品是根本没法用的。所以这个问题考的是你对 agent 鲁棒性和自修复机制的深度理解。 好，咱们把目光移到这张架构图上，大家看，要解决这个问题，绝对不是一个简单的脚本就能搞定的，我们需要构建一个全生命周期的防御体系。首先咱们看第一块，事前防御，你想啊，与其等他开口说话之前就给他立好规矩。注意看这里的 skma 强约束。 我们在定义工具的时候不能只给个名字，必须用像 pedantic 这种结构化的方式把参数类型死死锁住。比如这个参数必须是整数，你传个字母串进来，在模型输出的一瞬间，效应层就得把它拦下来。再往细了说， prompt 也很关键，咱们得在提示词里加上负面约束，明确告诉他，没给你的工具千万别瞎编，最好呢再给他几个 feel shot 例子，尤其是那些容易出错的边界场景，先打好预防针，但是模型总有不听话的时候，对吧？ 所以咱们看第二步试中拦截。大家注意这个红色区域，这是咱们的安全网。所有的工具调用外面必须套一层 try catch。 如果是 jason 解析错了，或者 api 接口挂了，咱们得能捕获到这些异常。 这里有一个非常重要的点，也是面试的加分项，就是高危操作的人工确认。你想想，如果 a 阵调错了一个扣款接口，或者误删了数据库，你光靠代码回滚可能都来不及。所以对于这种不可逆的操作，必须引入 human in the loop， 让人来看一眼再知情。同时， 咱们还可以做一个工具降级，比如 a 工具调不通，系统能不能自动路由到功能相似的 b 工具上。这种融洽意识，面试官非常看重。好，重点来了，如果错已经犯了， agent 怎么自己救自己？这就是第三阶段 闭环反馈与动态重试。以前咱们写代码报错了，可能就直接抛出异常了，但在 agent 体系里，报错信息其实是最好的教材。 我们要把报错的堆栈信息转化成大模型，能听懂的话，比如告诉他你刚才传的日期格式不对，应该是这样的。这就是 react 框架的精髓，把这个报错作为 observation 观察，结果未回给模型，模型看到这个反馈后，他会自己想，哦，原来我刚才把参数搞错了，那我得修正一下重新调。 这就形成了一个自修复的闭环。不过大家一定要注意，这里必须设置一个 max iteration， 最大重试次数，万一模型陷入了死循环，在那不停地报错，重试再报错，你的偷坑费可就烧不起了。 最后，我们要有事后进化的思想，大家看架构图最下面这一块，聪明的系统会复盘。我们可以引入一个专门的 reflection agent， 也就是反思智能体， 他不干别的，就盯着日制看，分析刚才为什么会调错工具，是工具描述不清晰，还是模型逻辑有问题。这些反思结果可以存进向量数据库，变成 agent 的 长期记忆。下次遇到类似的任务，他先解锁一下，以前的坑自然就避开了。甚至 我们可以把这些失败的案例攒起来，作为数据去 fiona 微调模型，从底层提高他调用工具的成功率。讲到这里，大家发现没有，处理工具调用错误，其实是一个从防患未然到临场应变，再到总结提高的过程。再面试。最后， 你可以这样给面试官做一个总结，咱们处理 agent 错误，核心要抓住四个点，第一，要有系统观，不仅仅是改 problem， 而是要构建一套闭环架构。第二，要直面共成痛点，像死循环、副作用、回滚这些坑你得提前想到方案。 第三，要利用好 react 原理，让报错信息成为模型自我进化的动力。第四，也是最高级的，就是平衡成本与效率。 我们要通过前端叫验，减少无效调用，通过反思机制降低重试次数，把每一分 token 都花在刀刃上。只要你能把这套逻辑讲清楚，面试官一定会觉得你是一个真正下过场踩过坑的 agent 专家。

今天聊一个很多人都在问的问题，怎么让 ai 写出来的代码真的能上线？你可能已经用了很多代码， agent 写项目，体感上确实快了，但如果你在一个真实的企业级项目里面对十几万行代码， rpc 框架、流程引擎、配置中心、分布式缓存、全套中间件，你大概率遇到过这个情况。 agent 写出来的代码语法完美，风格统一，但业务逻辑有微妙的错误。这种错误在编一层面没问题，但是实际运行却错漏百出。 为了修这些错误，形成恶性循环，不仅耗费金钱，还让代码仓库变成了一座屎山。比如价格字段用了 double， 而不是 long， 单位搞错了。比如改了主链路，但漏了国际化链路的同步修改。比如调用外部服务，没设超时和降级。这些错误有一个共同特点，它们不是模型不够聪明导致的， 模型的单步推理能力已经很强了。问题出在模型，不知道你项目里那些从来没被写下来的规矩。今天分享一下阿里团队的一个存量 java 项目上，用一周时间搭了一套 harness 体系， 把 ai 代码率从百分之二十五拉到了百分之九十。不是换了更强的模型，仅仅是根据 harness engineering 的 定义，搭了一套外部的约束和反馈系统。今天我就来拆这个实践，不讲概念，讲操作，你听完之后能直接在自己的项目里开始搭。先说一个背景， ai 工程实践正在经历第三次范式跃迁，第一次是 prompt engineering， 两千零二十二到两千零二十四年。核心是怎么写好一条指令， fewshot chain of dot 角色设定都是在优化单次交互。第二次是 context engineering， 两千零二十五年，核心是给 agent 看什么动态构建上下文窗口。 agentreg 解锁工具定义 shopify ceo 的 比喻是给邮件附上所有正确的附件。第三次是 harness engineering， 两千零二十六年，核心不再是一次对话或一次上下文窗口，而是设计跨越多个绘画、多个 a 阵角色、多个执行阶段的完整系统架构。 本质上来说，由于大模型的不确定性，每次你发现 a 阵犯了一个错误，你就需要花时间工程化地消除它再次发生的可能性。注意，不是修 prompt， 不是 加一句，请注意不要犯这个错，是工程化地消除， 意思是你要把这个约束变成一个文件、一条规则、一个自动化检查，让它成为系统的一部分，而不是一次性的口头叮嘱。为什么需要这么做？因为 agent 有 四种典型的失败模式。第一种，试图一步到位， 拿到复杂需求后， agent 倾向于在一个上下文窗口里完成所有工作，上下文填充率超过百分之四十之后，输出质量快速衰退， 开始出现幻觉循环、输出格式错误的工具调用。第二种，过早宣布胜利， agent 完成部分工作就说编码完成，但实际上翻译都过不了。 第三种，没做端到端验证就标记完成。 agent 认为功能实现了，但没跑过完整的测试部署后才发现关键路径不通。第四种，冷启动问题。每次新会话都要花大量 token 重新理解项目结构，真正用于编码的预算被严重挤压。这四种失败模式的共同根源是 agent 缺乏外部的结构化约束和反馈机制。 anthropic 在 他们的工程薄册里说得很直白， agent 无法准确评估自身产出的质量，你不能指望 agent 自己审查自己。好背景讲完了，现在进入实操。这个团队的做法是，在项目根目录下建一个 harness 目录， 里面放四样东西，规则、技能、知识库、变更记录。我一个一个讲。第一个规则体系，三份文件，工程结构开发流程规范、项目编码规范。这三份文件告诉 agent 标准是什么，不随需求变化的稳定约束。 比如工程结构文件里写清楚项目分几个模块，每个模块的职责是什么？分层架构是 controller、 service、 domain、 dow、 adapter 五层。比如编码规范里写清楚，价格字段必须用浪，类型单位为分，禁止 double 和 float。 外部服务调用必须设超时和降级。流程编排组建内不写大段。业务逻辑必须委托 service 处理。这些规则的特点是，它们不在代码里，但所有资深开发者都知道，以前靠口头传承，现在写成文件让 agent 也能知道。本质上讲就是给 agent 看详细的文档，进行软约束。 第二个技能体系，九个 skill， 每个 skill 是 一份结构化的 s o p。 最核心的是 coding skill， 里面有八份分层编码规范，从 controller 到 dow 到 adapter， 每一层怎么写都有明确的模板和约束。 a 阵的编码的时候不是凭感觉写，是按规范一层一层实现。 另一个关键 skill 是 expert reviewer， 这是一个评分 skill， 它定义了两种评分，循环计划评分和执行评分。 每条评审意见必须包含问题描述、修改建议和优先级分级。还有一个 unix right， 体现了改动驱动测试原则，改了哪个接口就测哪个接口，不是一刀切测最上层，而且要求优先，用线上真实请求的出入餐来构造测试数据。第三个知识库， 放在项目根目录的 wiki 文件夹里，列路梳理数据模型、核心业务流程，这些是 agent 理解业务上下文的素材， 但注意，知识库不会主动加载到上下文里。 agent 根据任务需要自主查找，这是按需获取，不是全量贯入。 第四个，变更管理每个需求，创建独立目录，从需求分析、文档、任务拆分、清单、编码报告、评审记录、 c i 结果到部署验证、全流程留痕、审批文件用版本递增，旧版本永远不删。这四样东西组合起来就是 agent 的 完整工作环境。但光有这四样东西还不够， 你还需要一个大脑来串联它们。这就是 agent 角色定义文件。这个团队定义了一个叫 application owner 的 agent 角色，它是整套体系的编排。中书定义文件大概四百行，包含五个模块。第一个模块角色和项目背景，二十到三十行，提供刚好够用的项目视野。第二个模块配置。中书缩影 用结构化表格列出 rules、 skills、 wiki、 mcp 四大组建的路径、职责、触发场景。这就是 anthropic 说的 index and map， 不是 百科全书，是地图。 agent 通过这张缩影表，在任意阶段快速定位到需要加载的知识。 第三个模块，七项核心职责，需求理解、任务拆解、任务分发、任务验收、质量把关、文档管理、知识问答。每项都有具体的行为准则。 第四个模块，工作流程调度指令定义了十个阶段的完整调度逻辑，每个阶段有出发条件、 skill、 加载指令、产出物路径、质量门禁条件、失败回退路径。 第五个模块，沟通原则和硬性约束必须做到和禁止做的两张清单。这个 agent 的 定义文件的本质是什么？是把一个资深开发者的工作习惯和决策逻辑编码化。 agent 不 需要学习怎么当一个好的项目 owner， 它只需要严格执行定义文件里的每一条指令。接下来是整套体系里最重要的设计。十阶段，开发流水线需求分析、需求审批编码实现编码凭证单侧编辑、单侧凭证代码推送、 ci 验证、部署验证、用户确认。 每个阶段都有三要素，触发条件、 skill、 加载质量门禁阶段之间有精确的回退路径， c i 失败但测试为零，回退到单侧编辑，编辑错误，回退到编码实现 需求不符，回退到需求分析不是出了问题，从头来是精确路由到该修的环节。审批环节有循环上线，需求审批最多三轮，编码审批最多两轮，超出后升级到人工决策，防止 agent 陷入无限的自我修改循环 流程里嵌入了五个人工确认点，需求代决意确认、计划评审后确认、编码评审后确认、部署环境参数确认、最终交付确认人始终掌握关键决策权。 这里有一个关键设计，分离执行和评判编码 agent 和评审 agent 是 分开的， anthropic 反复强调这一点，将做事的 agent 和评判的 agent 分 开是一个强有力的杠杆。 在这个团队的实践中，评审 agent 发现了编码 agent 遗漏的渠道判断逻辑，一个潜在的线上故障还在另一个需求中检测到 agent 试图跳过评审阶段并强制回退。 评审 agent 不 需要更聪明，它只需要用一套不同于编码 agent 的 检查视角来审视产出物。再说上下文管理，这个团队把项目知识按加载时机分三层，第一层， 绘画常驻 agent 定义文件，加三份 rules 文件，提供大局视野和基本约束，总量严格控制。第二层，阶段，触发进入需求分析阶段，加载 request analysis skill 编码阶段，加载 coding skill 和八份分层编码 spec。 评选阶段，加载 expert reviewer， 每个阶段只加载当前需要的知识。 第三层，按需查询 wiki 知识库，不主动加载 agent， 根据任务需要自主查阅。核心原则是让 agent 在 任何时刻都拥有刚好够用的上下文。不多不少 好实操部分讲完了，现在说几条关键经验。第一条，在拿真实需求使用之前，用一个虚拟需求完整走一遍全流程。这个团队在空跑中发现了四个缺陷， ci 门禁只检查状态码，而忽略测试用力数为零的异常 审查报告，在简单需求下不生成文件摘要文件因 agent 的 追加倾向出现重复行，部署参数被 agent 错误预测。这些问题如果在真实需求中才暴露，每一个都会导致严重反攻。 第二条，质量门禁必须可程序化验证。 open ai 百万行代码项目的核心经验，如果一个约束不能被机械化的执行， agent 就 会偏离检查 ci 是 否通过。这种自然语言描述不够， agent 可能认为状态 success 即通过，却忽略测试用力数为零， 改成三个可程序化验证的条件， status 等于 s u c c e s s total tests 大 于零， past 等于 total。 问题彻底消除。一切不可被机器验证的约束在 agent 执行中都是无效约束。 第三条，流程一致性优先于流程效率。一个仅涉及两个文件六行代码的小需求依然走完了完整的十阶段流程，一轮评审即通过，过程很流畅。 好的流程不应该给简单任务增加显著负担。当需求足够简单时，每个阶段的执行时间自然缩短。但流程的一致性保证了不会因为这次改动很小就跳过关键环节。在企业级系统中，小改动大事故的案例不胜枚举。 第四条，规范式活文档需要持续迭代，每次实战发现新问题都立即 patch 到 harness 中。规范的每一行都对应一个历史失败案例。 当你觉得某条规则多余或啰嗦的时候，那往往是因为它背后有一个真实踩过的坑。最后说效果，项目维度的 ai 代码率从百分之二十四点八六跃升到百分之九十点五四，个人维度从百分之十四点二四跃升到百分之八十七点八五。 这不是某个特殊需求的偶发峰值，是包含多个不同复杂度需求的常态化产出水平。但更重要的是，这百分之九十的 ai 代码经过了完整的需求分析、编码评审、单元测试和 c i 验证流程，每一行都通过了 harness 体系的质量门禁。高 ai 代码率本身不是目标，在质量可控前提下的高 ai 代码率才有意义。 最显著的效率收益不是 agent 写代码更快了，而是返工大幅减少。以往 agent 裸写代码后，人工 review 发现问题，要求返工的循环可能迭代三到五轮。有了 harness 后， agent 对 agent 的 审批闭环在内部就完成了大部分质量纠偏到人工确认时，通常只需要一轮。 一个意料之外的副产品是知识沉淀。 harness 目录下积累的规范文档、编码、 spec、 审查记录和变更历史，实际上构成了一份活的项目开发手册。 新人加入团队时，不再需要靠口头传授，无论是 agent 还是新人，都可以通过相同的阅读路径快速理解项目全貌。一句话总结， harness 的 价值不在于让 agent 变得更聪明，而在于让 agent 的 错误变得可控、可发现、可修复。 这和传统的软件质量保障思路一脉相承。我们不指望程序员写出零缺陷的代码，而是通过 code review、 unit testing、 c i、 c d 来确保缺陷被层层拦截。 harness 做的事情本质上完全一样，只不过拦截对象从程序员变成了 ai agent。 如果你想在自己的项目里开始搭，最小可行方案是三步，第一，写一份编码规范文件，把你项目里那些所有人都知道但从来没写下来的规矩写下来。 第二，写一个评选 skill， 让 a 镇在提交前自己审一遍。第三，加一个 ci 门禁，用可程序化验证的条件来卡质量。这三步做完，你就已经比裸用 a 镇的强了一个量。

你在实际的开发当中，你是怎么样保证 at 调用工具的可信呢？保证 at 调用工具的可信，不能只靠优化。 prom 核心是搭建一套全链路的预防拦截之余的体系，用四层工程架构兜底，解决大模型幻觉乱填、参数执行失控的问题。具体落地分四层，第一是结构化定义层，这是基础， 核心是给模型立好规矩，用节省做强类型约束，把参数的类型非空，要求每举值都定死，避免格式错误。 同时精细化打磨工具语义描述，像写 prompt 一 样，讲清不同场景该调哪个工具，从根源减少误判。第二个就是推理策略层，让模型想清楚再调，用 强制加思维链 c o t， 要求调动前输出思考过程，挡掉百分之八十低级错误。用 facebook 势利给模型正反模板，靠它的模仿能力提准确率。另外做工具与解锁，只给模型推和用户相关的问题， 减少干扰。第三个就是执行互拦层，相当于执行前的安检，绝不执行模型输出结果。用 padlet 做自动化校验，格式参数有问题就直接拦截，高风险操作，比如转账商户必须加用户手动确认，防止 a 键的失控。 第四个就是治愈修复层，这是体现工程能力的关键，不会直接给用户抛错工具执行报错的话，把报错信息原封不动的传给模型，让他根据错误重新生成参数。 工具调用完成之后，让模型校验结果，是不是解决问题不符合预期，就重新规划再次调用。那你能不能用一句话总结一下，保证 ag 的 调用工具的核心逻辑是什么？可以给他总结成一个公式， agent 的 调用可能性就等于高质量的结构化定义加严格的代码执行约束成以闭环的反思从事机制，本质就是不把希望全寄托在大模型本身， 而是通过四层架构做全链路管控，让 agent 的 工具调用从随机化变成标准化可控制能治愈的稳定执行，这才是生产级的保障核心。

大家好，欢迎收听今天的播客，我是大一，我是咪仔。今天我们要聊一个特别有意思的话题， ai agent 的 记忆。没错，最近有一篇论文引起了广泛关注，标题就很震撼，情境主体记忆是备忘录，而非真记忆。 这个标题太有意思了。简单来说，研究人员认为我们现在所谓的 ai 记忆，其实只是像一个备忘录，根本不是真正的记忆。那到底是怎么回事呢？让我们一起来深入了解一下这篇来自香港中文大学和浙江大学的研究。 说到 ai agent， 大家可能都听说过 m g、 p t、 reflection、 voyager 这些系统。是的，这些都是现在很火的智能体系统，它们有一个共同特点，用外部存储来保存信息，比如向量数据库。 研究人员把这叫做非参数记忆，就像一个外挂的硬盘，而模型本身学到的知识呢，就叫参数记忆，存在模型的权重里，问题就出在这里，很多人把这些外部查找机制当成 ai 的 真实记忆了， 但这其实是一个概念性的错误。打个比方，你在图书馆查资料，不能说你记住了那些书里的内容吧？ 说的好，研究人员打了个更形象的比喻，现在的人工智能发展，过度关注了记忆的海马体测，也就是快速存储，但忽视了新皮层测把经验慢慢整合成抽象规则的能力。 说白了就是现在的 ai 只会查笔记，不会长本事。为了更清楚的说明问题，研究人员把智能体记忆分成了四种类型。第一种是工作记忆，就像你做数学题时脑子里记的那些数字，用完就忘。 第二种是情景记忆，这个就是现在主流的把过去的对话记录存在外部数据库里，下次相似的问题再查出来用。 第三种是语义记忆，这是在训练时就学到的通用知识，比如地球是圆的。第四种是经验记忆，这是最关键的，把 ai 的 生活经验编码到他自己的脑子里，让他能真正改进推理能力。 问题就是，现在大多数系统都只停留在第二种情景记忆，他们用的是上下文工程，就是修改提示词来影响输出， 而不是原学习真正更新模型的权重，从经验中提炼出规律。这就好比一个学生只会抄笔记，从来不把知识内化成自己的能力。 接下来这个部分可能稍微硬核一点，但非常重要。研究人员提出了一个泛化鸿沟定律，用数学公式证明了基于剪辑的系统有根本性的局限。 想象一下， ai 学会了一些基本概念，现在要解决一个新任务，这个任务需要用 ai 没见过的方式组合这些概念。如果 ai 用的是剪辑式记忆，它就像一个查表高手，为了在新的组合上达到高准确率，它需要存储海量的例子。 但如果用的是参数记忆，真正学到底层规则需要的数据量就少了多。具体来说，剪所需要的样本数量和概念数的平方成正比，而参数记忆只需要和规则复杂度成正比。这就是为什么就算把上下文窗口做的再大，剪所算法再怎么优化，这个差距依然存在。 研究人员还用了一个很酷的证据，机械可解释性研究发现，事实关联其实高效的存储在模型的特定层里，实现了 r a g 根本无法复制的紧凑且可泛化的表示。所以你看，这是从理论到实践都证明了解锁的局限性。 说到这，我想起来研究人员提了一个特别形象的词，冻结的新手问题。这名字太有意思了，什么意思呢？ 想象一个经验丰富的医生和一个刚毕业的医学生。医生看过无数病例，随着经验积累，他的诊断能力越来越强，因为他在不断学习。但如果一个 ai agent 每次开新绘画时，模型权重都回到最初的状态呢？ 他虽然可以查阅外部图书馆里的历史日志，但没有从中学到任何东西。就像一个永远的新手，读了一辈子书，能力却一点没增长。这就是冻结的意思，能力被冻住了，永远停留在基线水平。 真正的专业知识是从慢慢解锁事实变成快速直觉应用的转变，但现在的架构完全阻止了这种转变的发生。所以哪怕他能调用一千条相关日制在新任务上表现平平，那他就没有真正学会任何东西。 说到这里，还有一个很严重的问题，安全漏洞。是的，研究人员专门提出了持久性损害这个概念。在普通的大语言模型里，如果遇到恶意提示，效果只是暂时的关掉，绘画就消失了。但如果恶意内容被写入了长期外部记忆呢？ 那可就麻烦了，这段恶意内容会在所有未来的绘画中被反复检测出来。研究人员还专门算了概率，如果每次绘画遇到恶意提示的概率是屁，那随着绘画次数 t 增加，记忆被污染的概率趋近于百分之一百， 这就造成了攻击面不对称。在权重层面投毒很难，但在上下文层面，植入恶意内容很容易，结果就是攻击容易，清除困难。这种设计简直是给黑客开了后门。 说了这么多问题，那有什么解决方案呢？研究人员提出了一个很优雅的思路，双系统架构，灵感来自人类大脑。具体来说就是两条路径并存。 第一条是情景路径，用快速的外部存储实现高保真即时的事件回忆，就像现在这样。第二条是巩固通道，这才是关键，缓慢的定期的把外部经验提炼，然后更新到模型权重里， 这模仿的就是大脑里的海马体和新皮层的分工。巩固通道就像一个过滤器和提炼器，他不会保存所有原始对话，而是识别成功的推理模式，提取新事实。 对于系统构建者来说，这意味着需要离线学习阶段智能体处理积累的日制，提升基础能力。 对于安全来说，这个通道提供了一个关键干预点，一个安全门，数据可以被清洗和验证后再永久写入模型，这样就大大降低了持久性损害的风险。最后，研究人员对整个社区提出了呼吁， 现在的精准测试都是测试 ai 从给定上下文里解锁信息的能力，但这是远远不够的。研究人员主张一个新指标随时间推移的组合泛化，英文缩写 c g t。 简单来说就是看 ai 在 接触过相关经验后，解决新任务的基础能力有没有提升。 如果一个 ai 可以 访问几千条相关网址，却在组合新任务上表现平平，那他在字面意义上就没有学会任何东西。研究人员的愿景是超越备忘录，构建真正具有随经验眼境的真实记忆的智能体。 这就需要 ai 社区重新介入持续学习领域，这个领域专门研究如何在数据流上训练模型而不会灾难性遗忘。 想象一下未来，真正学会从经验中学习的 ai， 那 是多么令人兴奋的画面。好了，今天的分享就到这里，感谢大家收听这期播课，如果觉得有用，别忘了分享给朋友哦！我是大一，我是咪仔，下期再见！

大家好，我是阿新，今天这期我们聊 agent 安全与失败模式，这个内容适合正在做 agent 工作流，工具调用、知识库解锁、自动化执行， 或者在设计企业 ai 应用的开发者和产品同学。接下来我会按，为什么 agent 更危险？最常见的失败怎么来？真正的防线放在哪？最后怎么把系统做成可接管的顺序讲。 先说最关键的一句， a 键的风险不再说错，而在做错后还会继续放大它。一旦调错，工具写错，文件发错，邮件污染，记忆错误就会延执行链扩散。 所以我们今天不讨论怎么让它永远不出错，而是讨论怎么让失败停得住，看得见、追得回。 很多人一听到 agent 安全，第一反应是把提示词写严一点，但这只是表层， 攻击者完全可以把恶意指令伪装成普通输入，甚至藏到网页、邮件、 pdf 或知识库里，让 agent 在 读取资料时无意中加载它。也就是说， prompt injection 不是 在和模型讲道理， 而是在把恶意命令伪装成数据。真正能挡住它的，不是继续堆提示词，而是工具白名单、参数、校验权限、上下文和高风险动作审批。模型可以提出动作，但系统决定动作能不能做。 aj 的 失败不止一种。第一类是工具越权，本来不该调用的工具被调用了，本来不该写的地方被写了。第二类是无限循环， aj 的 反复搜索，反复改，同一段内容在几个工具间来回切换，但没有新进展。 第三类是状态和记忆污染无关，资料失败尝试就假设留在上下文里，甚至被写进长期记忆，后面的任务继续引用，你会发现，这些问题很多时候不是模型傻，而是系统没把边界、停止条件和状态治理做清楚。 如果要给这些失败做一个更稳定的框架，可以看 master 是 specification 规范失败，意思是需求不清、目标冲突，导致 agent 从一开始就偏了。 a 是 agent， 指推理、循环、幻觉及联上下文损坏这类内部失败。 s 是 system， 指多 agent 通信故障、工具误用、验证、终止失败这类系统间失败。这个分层的好处是，你不会把所有问题都怪到模型头上。先分清是哪一层坏了，后面的修法才会对。 知道失败类型之后，下一步就是对症下药。工具越权靠的是最小权限和参数校验，状态污染靠的是临时信息和长期记忆。分层通信故障 靠的是结构化协议和执行追踪。验证与终止失败靠的是明确完成条件和多阶段审查。这里最容易犯的错就是拿一种防线想解决所有问题，那样只会让系统看起来更严，实际更脆。 多 agent 系统里通信不是大家随便聊聊，更稳的做法是把每条消息都设计成公单，至少要带上 sender、 receiver task id、 版本、自信度、风险标记和来源。 这样做的意义不是形式主义，而是为了审计、回放和定位责任。只要信息还是自由文本，系统就很难回答一个最基本的问题，这个结论来自哪一版，输入哪一个 agent， 哪一段证据。 还有两类经常被忽视的系统风险，一个是目标漂移，一个是资源耗尽。 目标漂移是指 agent 在 执行中越来越偏离原始目标，尤其是在开放式任务里，很容易越挖越深。最后，交付物和原任务只剩一点关系，资源耗尽则更直接。工具调用、搜索、上下文、累积 模型从事都会把成本和时间烧掉。方法也很朴素，最大步数重复检测进展、检查失败、升级系统，得知到什么时候该停，什么时候该换策略，什么时候该交给人。 安全系统最后一定要有人工接管，因为现实里你不可能让 agent 只有自动运行和失败退出两个状态，它至少要支持暂停执行、查看当前状态、查看工具历史、修改目标或约束、 要求某一步重做、跳过某个节点或者直接终止任务。这个能力不是补丁，而是安全的一部分。接管机制越清楚， agent 越敢用于真实业务。 如果把前面几页压成一张清单，核心就五件事，第一，输入要分数据和指令。 第二，工具要权限和校验。第三，状态和记忆要分层。第四，通信要结构化。第五，系统要允许暂停从事和接管。 再加上一个最简单的判断，关键事实有没有来源，高风险动作有没有审批，重复动作有没有检测资源上线有没有设。只要这几项做不到， agent 就 还停留在能跑，离可控还差得远。 最后再记住一句话， aint 安全的目标不是让系统永远不出错，而是让错误不能悄悄扩散。你只要能把输入、工具、状态、通信和接管这五件事管住， aint 才算真正进入可控状态。 好，这期我们就先聊到这里，如果这期对你有帮助，欢迎点个关注，也欢迎在评论区留下你最想防的那类 agent 事故，我们下期见。

你让 a i a 阵去完成一个复杂任务，他开头干得不错，结果中途老犯低级错误，走弯路，掐死所有搞 a i a 阵子的人都头疼这个问题， 直到这篇刚刚发布的论文出现。过去 a i a 阵学到的经验要么太粗糙，要么没法赋用长，任务一多，他就容易忘，容易乱，成功率很低。 各大实验室都在卷模型，但经验如何高效附用一直没解决。这篇论文提出 d s q。 双力度技能库， 它把 ai 的 经验分成两种，一种是任务技能，也就是高层次的规划，像攻略大纲一样。另一种是步骤技能，是细力度的动作，能实时纠错。 ai 边训练边动态更新技能库自动解锁、自动减脂，还能自我反思生成新技能。 实验显示，成功率直接提升十到二十个百分点。打个比方，以前 ai agent 像一个只会背整篇课文的学生，往往一句就卡壳。现在有了 d i skill， 它同时拥有 章节、目录和每句话的笔记，既懂大局，又能处理细节，不再是死记硬背，而是真正学会了方法论。这篇论文的最大价值，是让 ai agent 同一次性工具 变成能不断积累经验、自我进化的智能体，未来长时成自主， agent 会因此大幅变强。这可能是二零二六年 agnatic r l。 领域的重要突破。 这篇论文叫 dynamic dual granality skill bank for agnatic r l 里 r shift 刚出，我认为它非常值得关注。关注我继续给你吧。最新硬核 ai 论文，你觉得 ai agent 最需要提升哪个能力？评论区说说。

你有没有被 a 诊的误删过文件，或者透露过自己的一些个人隐私信息，怎么防范呢？我们来学习一种叫做人机协调或者叫做人工介入的方式， 它可以针对一些高风险的错，比如我们刚说的删除文件或者修改数据库，或者要用支付接口啊等等。 凡是这种具有不可逆性或者破坏性或者合规风险的，沃尔就可以让 ai 在 调用之前让人工呢再去确认一遍是否可以操作。所以这种机制呢，它是针对沃尔来进行精准拦截， 而你不需要介入的 to 呢？它依然是可以正常执行的，只有那些高风险的 to， 你 通过配置才会进行人工干预，比如我们人工同意或者拒绝 agent 才会执行后续的流程。那我们来通过 spring 阿里巴巴 agent 文档，以删除文件为例，看一下这个人工介入的机制是怎么实现的。首先它是通过后壳机制， 也就是它提供了一个内置的人工介入的 hulk， hulk 呢，我们之前也介绍过，它是专门用来拦截或者干预 agent 在 执行过程当中的一种方式。那么在这个人工介入的 hulk 当中，我们就可以进行配置，你需要 拦截的是哪一个工具进行人工介入，那么我们在下面就提供了一个叫做 delete file， 也就是删除文件的工具。 那么这里指定的这个名字就是我们看见这个 tool 的 时候指定的这个名字，好吧，不是这个类名啊，这里你要搞清楚。然后呢，你也可以给他提供一些 当触发了人工介入需要提供的描述，懂吧？所以我们要实现人工介入这个 human in the loop hope， 它是最关键的第一个点。那么第二个点呢，我们需要提供记忆的实现，因为在整个执行过程当中，如果出现了错误的拦截，需要人工介入， 你需要把之前的整个执行过程，它的聊天记录肯定都要存下来， 要不然你再进行后续的执行，前面的聊天记录都忘了，那肯定是不行的。所以在这里呢，我就提供了当然最简单的记忆实现，我们之前呢也讲过 radis 来存储记忆，你也可以改成 radis 的 记忆实现，好吧， 所以这是它的第二个关键点，第三个关键点，通过 react agent 去直定我们刚刚声明的这个 human in the loop hook， 那 么另外你这里进行人工干预的这个 to 肯定也要配置进去，好吧，所以我们这里除了一个删除文件的 to， 还有一个 查询文件列表的 to 来我们运行看一下这个结果。那么在这里呢，我会通过 spring ai 阿里巴巴生态下的 studio， 也就是这个聊天 ui 界面来进行演示，毕竟这个视力当中呢，它需要我们人工的进行审批，是同意还是拒绝， 这里涉及到一些 ui 的 交互，如果我们要自己去实现的话比较麻烦，毕竟它的生态当中呢，都已经实现了，我们直接就用它的这个现成的轮子来去演示。那么现在比如说我让他给我删除文件， 我随意地去指定一个，比如说第一盘 temp 下的询数这个文件，那么此时你就可以看到它就会去调用我们的 delete field tool， 并且把这个要删除的文件作为参数传进去了， 所以在这里就触发了人工介入，这里呢有三个选项，第一个是同意拒绝，还有修改同意跟拒绝呢，就很好理解，对吧？同意肯定就会直接去调用这个 tool 执行删除， 那么拒绝呢，肯定就直接就会中断我们当前的呃执行，就不会去调用这个工具了。那么另外呢，还有一个修改，这里就可以去修改 调用这个库涉及到的参数。比如我不让他删除徐树，我让他删除徐树六六六这个文件，那么在这里就可以保存，然后再提交，此时呢你就会发现他删除的就是徐树六六六这个文件，你看到没有？ 那么我这里呢，这个学术六六六的文件就没有了，之前是有的，那我们再来说一下它又是怎么运作的呢？其实核心机制是借助我们之前讲的这个 hock， hock 它主要的特性就是可以去中断或者停止干预我们 agent 执行过程，只借助 hocks 的 话还不够， 这里涉及到了一个叫做 interruptible action 这样的一个机制，它其实就是一个接口，我们可以稍微看一下源码，它这里啊实现了一个叫做 interruptible action 的 这样的一个接口， 那么这个接口呢，它提供了一个方法叫做 interrupt， 这个方法如果你直接返回的是一个空值， 那么就代表呢我不会中断。如果你返回的是一个 interuptation meta data， 那 么它就会触发中断。所以在这里呢，它主要就是借助的这个 interruptable action， 在 agent 执行过程当中呢，它的底层就会自动判断你的 code 有 没有实现这个接口，如果实现了， 它就会去调用 interrupt 的 方法，看你是否需要中断，好吧，如果需要中断呢，它就会去翻译一个 interruption meta data 的 数据返回给前端，那么前端接收到你这个数据呢，就会构建出一个人工反馈的界面出来， 进而呢再提交给 agent。 那 么这一块的源码我们也可以稍微看一下，也就是这个 interrupt data 它是怎么返回给前端的，这里呢会涉及到我们需要通过这个阿里巴巴 studio 这一块的源码来进行观看，也就是我们在这里点击这个发送按钮， 它实际上就会去调用阿里巴巴 studio 这个 execution 控制器里面的这个 run sse 接口，然后呢就会接收到用户发送的消息，然后去执行这个 execute agent， 那 么在里面呢进行流式的请求，然后进行响应式的判断当前的消息类型， 那么其中呢，就有一个判断分支，判断当前是不是 interuptation metadata， 如果是的话，那么就把当前的 这个所需要的数据构建成一个 dto 传递给前端，那么前端一旦通过 或者拒绝，然后点击这个 sub meet 按钮，就会去调用另外一个接口，也就是这个 read consumer s s e 接口，从而呢就会拿到前端返回的这个结果，封装在了这个 result 的 结果里面，然后呢就会再一次地去执行 agent 的 stream 流逝响应的方法，继续 执行下面的操作。那由于我们的记忆是通过当前的这个对话 siri 的 id， 也就是我们每一次对话呢，都会有一个 siri 的 id 作为当前对话窗口的记忆存储，所以当我们再一次去提交用户接入的反馈， 他是知道我们之前对应的聊天记录的，然后呢，就可以继续执行后面的操作了。那我这里整理了一套 java 程序员学习 ai 的 完整学习路线图，加完整学习视频加配套代码笔记加 配套的项目实战，从大模型选型到微调，再到 ai 开发 agent 的 框架，最后到项目实战，你像智能客服 reg 知识库，手撸小龙虾，垂直 agent 的 workflow 流程开发，最后到部署。为了让大家更好地去面试呢，还整理了一套 java 加 ai 的 高频面试资料，通通无偿分享，需要的小伙伴留下 ai 就 行， nice！

openkey 不 推荐的用法。错误用法一，把 a p i t 铭文写在代码里。后果，一旦不小心被破少的 app 后会被扫描滥用。正确做法，通过别的脚本文件来设置环境变量。错误用法二，没有成本上线就上生产，后果， 一次被可能产生大额账单。正确做法，要去设置硬性的上限。错误用法三，让 a 制你直接去执行不可逆的操作。后果，删除电脑文件，发送消息无法撤回。 正确做法，不可逆的操作前需人工确认。错误用法四，搜点 md 写你可以做任何事情，后果， 没有约束的 a 证很容易出错。正确做法，要明确说明能做的和不能做的。错误用法五，单点依赖某一个大模型提供商。后果，提供商故障涨价断浮时可能导致业务中断。正确做法，要配置至少两个不同提供商的大模型， 出问题就换。错误用法六，不是 a 准你的输出验证后果，给准你编造数据换绝结果被当做正确的正确做法，关键输出必须有验证步骤，数据库查询确认，人工审核。错误用法七，对话历史永久保留，后果 随时间增，每次调用越来越慢。何贵正确做法，设置历史度限制，超出后压缩或删除。

别再直卷 prompt engineering 和 context engineering 了，大厂已经在偷偷用 harness engineering。 接下来我们就来聊聊 harness engineering。 我是 悟空，想了解更多面试题，点击主页，我们马上开始，我们通过这七点，让大家彻底清除 harness engineering。 一、 什么是 harness engineering？ 二、三个工程的区别大白话解析三、 harness engineering 在 企业中的应用四、企业真实案例分享 五、 harness 系统核心模块六、三步落地法七、风险提醒，你还在死磕 prompt， 太慢了。 anthropic open ai， google 内部早就不比谁 prompt 写得好，比的是谁的码据更稳，这叫 harness engineering， 随便一个人都能写 prompt 会点 r a g 就 敢说自己懂 context engineering。 但真正在生产环境中应用 a 阵的团队已经在聊一个新词， harness engineering， 执意马具工程模型就像一匹很有力量的马，但它不一定知道往哪儿跑，工程师是骑手，负责给方向。 harness 就是 那套马具，把模型的能力约束住，引导好真正用起来的完整系统核心。 prompt 是 教模型怎么回答， harness 是 设计模型怎么工作？三个工程的区别用大白话讲透。 我打个你一定能记住的比方， prompt engineering， 你 对司机说前面右转 context engineering， 你 给司机一张地图，告诉他前面是哪个路口。 harness engineering， 整辆车的系统，方向盘、刹车、导航、车道保持自动报警安全带。 harness engineering 在 企业中的应用， 在企业里，一个 agent 要跑通复杂任务，光有好 prompt 和一堆文档远远不够。你需要回答这几个问题，模型接到任务后怎么拆？怎么调用工具？怎么记录状态？ 怎么验证结果？什么时候让人接管？这一整套运行机制就是 harness 企业真实案例。案例一， anthropic 编程 agent 任务拆分为 planner 规划、 generator 生成、 evaluator 评估三段式，关键是外部进度文件记录状态，并由独立评估器验证，避免模型自我感觉良好。案例二， openai 的 工程护栏增加确定性验证，如 link 单元测试代码规范， 模型生成代码后必须通过自动检查，另有 agent 持续扫描项目检查不一致和违规。案例三， google deepmind 数学研究， agent， 一个模块提解法，一个模块找漏洞，一个模块修错误，再次验证了生成和评估分离的重要性，防止模型对错误结果过于自信。案例四，我在 app 中小团队经验， 减少 agent 能用的工具数量，反而提升了效率。工具太多， agent 会迷路，适当减少选择空间能让其更稳定。 harness 系统必须包含的六个模块，一个成熟的企业及 harness 至少要包含这六样东西。一、上下文管理，通过 agent、 md 等方式明确项目规则、目录结构，禁止事项常见坑。二、 工具编排，精选工具通过统一协议接入，并用沙箱隔离风险。三、验证机制，代码类任务用 linter 加单元测试， 业务类任务用规则较严多 agent 的 互审或人工确认。四、状态管理，使用偷斗、日制提交快照等方式记录进度，保证失败能回滚。五、可观测性，必须能追踪 agent 失败的原因是上下文工具验证还是权限问题？六，人类接管涉及高风险操作，删库扣费、修改线上配置时必须由人工确认。三步落地法，如果你现在就想在企业里落地，按这三步走，短期在项目根目录建一个 agent meeting， 把 agent 经常犯的错误代码规范写进去，中期接入确定性验证， linter 单元测试并记录 agent 每一步做了什么。长期把整个 harness 做成模块化，以后换新模型时外部系统还能复用，不用全部退到重来。风险提醒， 但也要小心两个坑，概念炒作，别随便写个 prompt， 加个工具调用就自称 harness。 概念被炒大，但落地很糙，过度工程化，模型能力在进化，有些复杂的补丁明天可能就不需要了。多 agent 也不是万能药，偷肯贵炼卤肠更不可控。核心理念， harness 不是 堆模块， 而是用最小系统解决最关键的不稳定问题。总结， prompt 优化一句话， context 优化一段信息， harness 优化一整套系统。未来这个词可能会变，但思想不会消失。只要还想让 agent 进真实业务，就不能只追模型更聪明，还要让它更可控。觉得有用。点赞收藏加关注评论区，聊聊你遇到过 agent 迷路的瞬间吗？

今天想把一件事说清楚， ai agent 到底是怎么工作的？有一个公式可以直接点提， agent 等于 model 加 harness。 model 就是 模型本身，只负责推理除此之外的一切工具，执行上下文管理、安全约束、错误恢复、状态持久化，全部属于 harness 的 工作。 理解这个分工是理解 agent 工程的起点。 harness 这个词介字，软件测试领域，只把被测代码套进一套固定装置里，统一驱动和检测。 在 ai agent 的 语境里，它的含义扩展了只包裹模型的整套运行时基础设施。公式很简单， agent 等于 model 加 harness， 模型只负责推理其余的全规 harness 管工具的调用与执行、上下文的组织与传递、安全边界的约束，出错后的恢复逻辑以及跨轮次的状态持久化。换句话说，模型是大脑， harness 是 让这个大脑能在真实环境里持续运转的一切支撑结构。 harness 控制 agent 行为的方式分两类，第一类叫盖茨，属于前馈控制，在 agent 采取行动之前介入，通过 agents md、 规则文件架构文档、技能文件这类材料提前告诉 agent 该怎么做，目标是提高第一次就做对的概率。 第二类叫 sensors， 属于反馈控制，在 agent 行动之后，检测结果触发自我纠正。典型工具包括 e s link 类型检查器、测试套件以及 ai 代码审查。 agent 两类控制一前一后，构成完整的闭环。 guides 负责预防， sensors 负责兜底。 前馈控制最核心的落地形式是几类规则文件和工具， agents md 或 cloud md 是 最直接的一种，把项目约定、禁止行为代码风格写进去， agent 每次启动都会读取 skills 文件，更犀利度。针对特定任务类型给出分布指令，比如如何新增一个 a p i 端点或如何写测试。 kolmas 则是可执行的代码变换脚本，直接对代码库做结构性修改，不依赖 agent 自己推断怎么改。 这三类工具的共同目标只有一个，让 agent 第一次就做对，而不是靠后续反馈、反复纠错反馈实现从清到重。大概分这几层，最基础的是 linter， 比如 e s lint 或 sgrp， 运行在毫秒级捕获风格违规和结构性问题。 往上一层是类型检查器和测试套件覆盖逻辑性问题网上一层是类型检查器和测试套件覆盖逻辑方向有没有漂移。 最顶层是 ai 代码审查， agent 处理需要语义判断的问题。这里有个关键细节， linter 的 报错消息本身应该针对 llm 消费来设计，直接在消息里嵌入纠正指令，让 agent 读到错误的同时就知道怎么改，形成正向提示。注入两种空 过渡工程，代价是速度慢，结果非确定性成本高，不适合每次提交都触发。两者覆盖的失败模式几乎不重叠， 只用计算型与一层的问题会漏掉，只用推理型，结构性问题的检测成本会高得不现实。把两者组合进同一个 harness 才能覆盖 agent 在 实际工程中遇到的大多数失败模式来看，一组 中手写的是临行，整个过程处理了大约一千五百个 pr， 人均每天处理三点五个，折算下来效率大概是传统开发的十倍。 团队后来扩展到七人，吞吐量还在继续增长，这直接违反了布鲁克斯法则，原因并不神秘。工程师之间的代码层面藕合被消除了，每个人只需要关注自己负责的 harness 环境。设计 agent 在 工程师睡觉时持续运行，单任务超过六小时是常态。 这组数字背后，支撑它运转的正是一套完整的 harness 基础设施。 harness 有 三个调节维度， 第一个是可维护性，也就是代码质量层面的约束。这个方向工具链最成熟， linter 类型、检查圈、复杂度分析都有现成方案。第二个是架构适配性，通过 fitness functions 来定义和持续检查架构特征，比如层间依赖方向、模块边界 c i 自动验证 agent， 不 过就改。 第三个是行为正确性，这是目前最难解决的维度，主要靠 a a 生成测试套件加人工测试兜底。对 a a 生成测试的信任度还不够，是整个领域待解决的核心问题。 我倾向于把 agents md 控制在一百行以内，让它只充当目录。具体的设计文档、架构说明、执行计划、产品规格全部分散放在 dax 的 结构化子目录里， agent 需要哪块知识就去取哪块，不需要一次性把所有规则都塞进上下文。 这种渐近式批漏的方式，既避免了超长文件挤占 talk， 也让每份文档的职责更单一，更容易维护。 模型是引擎， harness 是 轨道，两者缺一不可。光有强大的模型，没有工具执行上下文管理错误恢复这套基础设施， agent 跑不远。 真正决定 agent 能走多远的，是你在模型外面搭建的那套 harness。 从现在开始把 harness engineering 当做和模型选型同等重要的事来做。

最近手指受伤了，骨折了，现在回家弄这个 ai， 是 那个爱马仕的 agent 出了一个问题，它就是老是超时安装这个老是超时， 应该是这个，现在就是搞了一天终于能下了。它主要是哪一个呢？就是一定要把这个打开，这个 h y p r， e， v 这个一定要打开它才能下载， 这个下了好久， win 加 r 输入这个，这这个字英文我也不认识，然后点确定它就会调出这个，然后要把这个给打开，最下面的就是这个虚拟的还有应用， linux 的 windows 的 子系统 它都会打开，这样子就能够避免那个操作超时的问题。

如果一个 aint 回答完成了，但数据库里根本没有订单，这算成功吗？这就是 a n s r opik 这篇文章真正要拆开的错节。 aint 评测不能只看最后那句话。传统模型向答题输入一个 prompt， 检查一个回答。 aint 不 一样，它会调用工具，改文件，查网页，更新状态，还会在中间，结果项继续决策。 错误不是停在一句话里，而是会沿着环境传播。所以一个靠谱 evl 至少要看六件事，辨悟是什么，跑了几次，完整轨迹是什么，最终环境变成什么样，谁来评分以及什么。 harness 负责把这一切稳定地跑起来。 这里最关键的奖项是 transcript， 只是过程， outcome 才是结果。用户看到机票已预订没有意义，真正要验证的是预订记录、支付状态、通知邮件这些外部事实。为什么团队会忽视它？ 因为原型期靠人工试用真的很快。问题出现在象限之后，用户修感觉变差了，工程期只能复现 修补，再祈祷别把别的地方改坏。 a y l 的 价值是把这种反应系循环变成可运行的计量系统，每一次失败都能变成侧系用力，每一次模型星级都能先跑基线，每一次产品精论都能落到清晰几标项。 评分器也不能只有一种代码。评分器快，便宜、可复现，适合单元测试、静态分析和状态检查。模型评分器能处理开放质量，但必须有 rubric， 还要用人类判断校准人类评分最慢却是校准复杂判断的金标准。真正成熟的做法，像多层防线 自动 a y l 抓回归生产监控，看间隙分布，人工读 transcript， 搅那些自动规则看不见的戏外玩家还提醒一个常见误区，能力评测和回归评测不是一条线，能力评测应该难起步，通过率低，给团队一座山爬。回归评测应该接近满分， 负责守住已经会做的事。随机性让 a 键分秀更微妙，至少一次成功率会随着强习次数向升，连续成功率却会下降。一个单次成功率百分之七十五的 agent， 连续三次都成功，只剩大约百分之四十二，这就是为什么只下高分。 benchmark 很 危险。 对探索型工具，你可能关心多试几次能不能做出来，但对客服、浏览器控制、财务操作，用户要的是每一次都可靠，从零开始，不用先造。进行 benchmark a n s r optic 的 建议反而很朴素， 先收集二十到五十个真实失败，把人工检查、工单、用户投诉翻译成可判定的任务。好任务必须无歧义，有参考解法，环境要隔离问题及要平衡。别急测该搜索时会不会搜索，也要测不该搜索时能不能忍住，否则 a、 y l 会训练出另一种偏差。 还有一个残酷点，低分不一定说明模型差，也可能是规定坏了，任务不清、路径限制太死、环境泄露、评分太脆，都会把有效解法判成失败，所以必须读 transcript。 最后， a 将 evl 不是 给模型贴分数，而是给团队一套共同语言 产品定义成功攻城守就回归研究优化能力、运营发现漂移，你测得越清楚， a 键才能越大胆地变强。

最可怕的 agent 不是 停了，而是他一直在把错误做完整。这就是 ralph loop 最早想解决的问题。什么是 ralph loop？ 简单说就是别让 agent 一 条绘画从头撑到尾。他没做完就开新一轮继续， 但重点不是继续，而都每一轮都从相对干净的上下文重新开始，再通过文件代码测试和 get history 接上之前的进展。 为什么这重要？因为长任务里聊天记录会越来越脏，失败猜测、日制临时判断，全堆在一个上下文里，跑到后面 a 阵的自己都可能分不清哪些是事实，哪些是假设，哪些已经验证过，哪些只是上一轮随口写下的判断。 所以 rough loop 真正有价值的不只是循环，而是两个东西，上下文重置外部状态。后来 codex 的 go 其实是把这条路往前推了一步，他给 agent 一个持续目标，让他不要每隔几分钟就停下来问你要不要继续。这当然有用， 以前跑长一点的 ai 编程任务，经常是活没干完， a 阵子先停了，人回来补一句继续，他又得重新热身。 go 解决的是持续性， 但问题是能一直干不等于干的。对。一个 agent 跑几个小时，跨几个上下门，窗口，中间还可能叫 sub agent 最后交出来的东西能不能验证，能不能审查，能不能让下一个人或者下一个 agent 接着干， 这才是长周期 agent 真正的门槛。因为长任务最容易出现三种漂移。第一，目标漂移。 你本来只是让他修一个 bug， 跑着跑着，他开始顺手重构，顺手优化，顺手加功能。最后，东西很多，但已经不是你最初要的结果。 第二，上下文漂移。上下文被压缩截断，总结之后，关键信息可能丢了。后面的 agent 他 还以为自己掌握了大局，其实是在残缺，事实上继续推理。 第三，质量漂移，局部测试过了，他以为全区完成了，一条路径跑通了，他以为系统可用了。这就是长城 agent 最危险的地方，它不是突然坏掉，而都每一轮都偏一点，最后还看起来很自洽。 所以长周期 agent 不 能只靠聊天记录续命，它需要外部状态文件，比如 go 点 m d 写清楚目标， pln 点 md 写清楚计划 standards 点 md 写清楚规则， progress 点 md 写清楚进度卡点和下一步。这些文件不是形式主义，它们是留给下一任执行者的接管证据。 因为真正生产级的长城 agent 不是 跑完就结束，而是任何时候换人、换模型、换 agent 都能接得住。 接手的人至少要知道当前目标是什么，哪些已经是事实，哪些只是猜测，哪些决策不能随便推翻。最近的安全回滚点在哪里？哪些测试证明他真的做对了？如果这些答不上来， a 阵跑得越久，就越像一个没人敢碰的黑河。 sub agent 也是一样，它真正的价值不是角色扮演，不是起几个名字叫 planner， coder、 reviewer 就 高级了。 subagent 的 第一层价值是独立上下文实现者很容易相信自己的判断，所以你需要一个 fresh reviewer， 他 不继承前面的心理负担，只看目标 def 标准和测试结果，重新判断。这次改动真的满足目标吗？有没有改除需求之外的东西？ 测试是不是只覆盖了快乐路径？旧行为有没有被悄悄破坏？所以从 ralph loop 到 codex goal， 再到可接管 harness， 这条线真正讲的不是怎么让 agent 跑更久，而是怎么让 agent 跑完以后现场还清楚，目标状态、决策、验证、回滚点，这些东西连起来才是一条可接管证据链。 一句话总结，长城 agent 的 下一道坎不是一直干，而是干了很久以后，人和下一个 agent 还能不能接得住？ 接得住才叫生产级，接不住就是一个跑的更久更贵更危险的黑河。你觉得长城 a 镇最大的问题是半路停掉还是一直跑偏却没人发现？评论区聊聊？关注我，下期继续带你拆！

我发现很多人做 agent， 一 上来就犯一个致命的错误，以为记忆就是多存点东西，那错了， agent 的 记忆不是仓库，不是垃圾桶，更不是把所有的聊天记录一股脑的塞进 prompt。 那 真正高级的记忆设计呢？其实就一句话，在对的时间把对的信息给到模型。因为大模型本质上呢，不是一个天然稳定的长期记忆系统， 它更像一个短时工作的大脑，当前上下文理很聪明，但是一旦跨轮次、跨任务、跨时间，就容易断篇。所以 agent 记忆机制本质上其实是解决两个问题，第一，什么信息值得被记住？ 第二，需要的时候怎么高质量的取回来？那先说第一层记忆分两种，短期记忆和长期记忆。短期记忆管的是当前的任务连续性，比如这轮任务做到哪一步了？用户刚刚改了什么要求？上一步工具执行结果是什么？ 那这东西呢，更像县城类的状态，不求永久保存，但必须保证任务不断篇。长期记忆的话呢，管的是跨任务复用，比如用户编号、历史项目经验，比如用户是产品经理篇号，中文表达公司做弊端的 size， 这些都是稳定的事实。那第二类情节记忆就是发生过什么， 比如上一次写 p、 r、 d， 试过三种方案，最后用户接受了哪一种？第三类程序性记忆就是应该怎么做？ 比如说做竞品分析，要先拆解场景，再拆功能，再拆指标。写方案呢，要先给框架，再补细节。这类的记忆最值钱，因为它沉淀的是工作流。那产品设计上呢，重点要看两个机制， 写入机制和召回机制写入不是啥都记，你什么都记的话一定会变成噪音仓库。那真正该记的只有三类，用户明确表达的长期偏好、重复出现的稳定事实，以及任务复盘里被证明有效的方法。怎么写？两种方式，一种是主链路实时写入，优点呢是马上可用， 那另一种是后台异步总结沉淀，优点就是不影响当前的任务速度。实际产品里呢，通常两种都需要结合。再说召回，召回的关键呢，不是全量塞回 prompt， 而是按需解锁动态加载。那记住，上下文窗口是稀缺资源，你塞进去的每一句废话都在挤掉真正重要的信息。 所以 agent 调记忆时，应该先判断当前的任务到底需要哪些历史信息，哪些偏好相关，哪些经验可复用， 然后只拉回少量的高信息记忆，必要的时候还要做摘药压缩。最后还有一个很多人忽略的点，遗忘机制， agent 不 能只会记，还要会删。那错误的、过期的、低执行度的信息呢？如果一直留着，时间久了就会被污染决策。所以每条记忆都应该要带属性来源、时间、适用范围、 可信度、执行效果。如果一条片号连续被用户反馈推翻，或者是每条经验多次失效，就应该降权甚至淘汰。所以你看 agent 的 记忆系统根本不是存聊天记录这么简单，它应该是一个可写入、可召回、可压缩、可纠错、可治理的知识层。如果你是 ai 产品经理，记住这句话， 不会设计记忆机制。你做的 agent 永远只能像一个临时工会设计记忆机制，它才开始像一个真正懂用户、懂任务、懂赋盘的智能助手。那我也整理了一份大厂 ai 产品经理必须掌握的能力文档，里面包括了 ai 产品研发流程、大模型的未来发展方向，以及当前的 ai 产品落地最容易踩的坑。想系统补这一块的可以去看一下。

今天咱们聚焦一道大模型算法岗的高频面试题， agent 与 rpa 有 什么差别？ 首先，我要先指出一个百分之九十的人都会踩的坑，也是最常见的错误答案。很多同学面试时一开口就说 agent 和 rpa 都是做自动化的， agent 就是 加了大模型的升级版。 rpa 本质没区别，就是更智能一点。 我明确告诉大家，只要你这么答，面试官直接给你打不及格，这轮面试基本就结束了。 先把跟上的区别掰明白， rpa 的 本质是规则驱动的流程执行工具， agent 的 本质是目标驱动的智能决策体。这一句话就划清了两者的核心边界，也是面试时的核心得分点。 接下来我们从三个核心维度把差别拆解的明明白白，面试时照着说就能碾压同场竞争者。 第一，驱动逻辑天差地别， rpa 是 你教他怎么干，必须写死每一步执行规则，他只会严格按指令走，规则外的事半分都不会做。比如你让 rpa 导销售报表， 必须告诉他点哪个按钮，输什么，筛选条件文件存到哪个文件夹，但凡报表格式改一个单元格，他直接崩了，完全不会变通。 而 agent 是 你告诉他要干什么，你只需要给最终目标，他会自己拆解任务规划步骤，调用工具，全程不用你插手。同样做报表， 你只需要说出一份本月销售分析报告，找出业绩下滑的核心原因，它会自己导数据做，分析出报表，甚至自主核对异常数据。 第二，决策容错能力完全不是一个量级。 r p a 是 零决策零容错，没有任何思考能力，执行环节和预设规则有一点不一样，直接报错停止。 比如让他给一百个客户发邀约邮件，一个邮箱格式错了，他直接停摆，不会跳过，更不会主动找正确的联系方式。 r p a 是 零决策，零容错，没有任何思考能力， 执行环节和预设规则有一点不一样，直接报错停止。比如让他给一百个客户发邀约邮件，一个邮箱格式错了，他直接停摆。 而 agent 有 完整的感知决策、执行、反思闭环，遇到异常会自主解决，甚至优化执行策略。同样发邮件，他会自己查找无效邮箱的正确联系方式， 根据客户行业定制化修改邮件内容，发完还会跟进回复，做客户意向分类。 第三，适用场景边界完全不同。 rpa 只能搞定标准化、高重复、规则明确的固定流程， 边界极窄，跨系统、跨场景的任务基本做不了。 rpa 只能搞定标准化、高重复、规则明确的固定流程，边界极窄，跨系统、跨场景的任务基本做不了。 而 agent 能处理非结构化、动态变化、边界模糊的复杂任务，能跨系统、跨工具完成全链路工作。比如从选品到投流的全链路电商运营， agent 能全程自主完成。 最后给大家整理好面试直接背的满分话术，记牢这句话，面试不慌！面试官您好！ agent 和 rpa 有 本质区别，核心体现在三点，一是驱动逻辑不同。 rpa 是 规则驱动，只能执行预设的固定流程。 agent 是 目标驱动，可自主拆解任务，规划执行路径。二是决策能力不同。 rpa 无自主决策能力，零容错。 agent 具备感知、决策、执行、反思的完整闭环，可自主处理异常优化策略。 三是适用场景不同， rpa 仅适用于标准化、高重复的固定流程。 agent 可处理非结构化、边界模糊的复杂任务，除场景，跨工具完成全链路工作，两者并非升级替代关系，而是可以互补配合。 rpa 可以 作为 agent 的 执行工具之一。希望今天的讲解能帮大家吃透这道题，面试时轻松拿分，顺利拿到心仪的 offer！