“我不想再做一个‘记忆型 AI’我们花几天时间把一个个人 Agent 推到了可以真正开工的阶段”——单看这个标题可能很多人会觉得我们在做某种“带记忆的聊天机器人”。但恰恰相反这三天里我们做的最重要的一件事就是把“记忆”从 Agent 的核心位置上拉下来把“执行闭环”提到最上面去。最近一两年 Agent 类项目确实火但说实话我在社区里看到大量“Agent 项目”其实都停留在同一个阶段能记住你上次说了什么能根据当前对话调一下函数能搜索一下网页然后给你一个像模像样的回答。这类项目说白了是“记忆型 AI”——它把一切能力都建立在上下文里没有真正的任务拆解、没有可验证的产出物、没有“做不完就不该说自己做完了”的边界控制。我们这次的目标很明确不要那种会聊天、会复述、会“看起来有推理能力”的东西而是要一个能真正开工、能在没有人类盯着的情况下把一件具体事务推进到可交付状态的个人 Agent。这篇文章我会把我们这三天从原型验证、架构推翻、记忆重构到最终跑通真实用例的全部过程拆开讲。重点不是分享一个神奇的 Demo而是讲清楚哪些设计是必须自己动手实现的哪些看似高级的组件根本可以不做以及“真正能开工的 Agent”和“演示用的 Agent”之间到底隔了几层。1.1 我们最初踩中的多数人误区把“能干活”定义成了“能回答问题”先说我们一开始做的事。为了节省时间我们第一天直接上了一套主流路线预训练的对话模型 向量数据库做长期记忆 函数调用能力让模型能操作外部工具。很快我们做出一个东西你跟它说“我本周要写一份产品竞品分析报告”它会记住这句话会帮你搜索资料然后输出一份结构完整的报告。第一次看到效果的时候团队里有人说这已经可以拿出来演示了。但等到真正让它“独立开工”的那一步问题全出来了。第一个问题是任务拆解深度不够。它会问你“报告要包含哪些维度”如果你不回答它就按默认模板生成一份“什么都有但什么都浅”的文档。第二个问题是过程校验几乎为零。它搜索到资料之后不会判断这些资料是否真实可靠很多时候把营销软文当成了权威数据源。第三个问题更致命它没有“交付”的边界感。你以为它做完了报告其实它只是生成了一段让你“接着问”的文本。它不会主动检查文件是否生成、格式是否合格、有没有遗漏关键章节因为它的训练目标里就没有“把任务真正了结”这件事。我们把这种状态归结为“记忆型 AI 的典型症状”它记住的信息越多越容易让用户误以为它在做事。实际上它只是在用丰富的上下文生成一个又一个“下一步回复”。而这个“下一步回复”离“事务完成”之间还隔着一整套关于任务状态、执行策略和验收标准的设计。我们当时就决定必须在第二天把整个架构推倒重来。1.2 重新定义“开工”必须具备的三个可观测能力推倒重来之前我们先把目标重新写了一遍。我们不追求一个通用助手而是让 Agent 在“个人助理”这个场景下真正能开工。最终我们把“开工”定义成三条硬标准缺一不可。第一任务必须能被拆成可验证的中间产物。不是“写个报告大纲”这种模糊表述而是“产出 markdown 文件包含标题、核心论点、证据列表、反方观点、结论建议”这种能被脚本检查的结构化产物。第二Agent 必须能在没有人类持续介入的情况下独立完成一个完整循环。也就是说从接受任务、规划步骤、执行动作、检查结果到发现失败后调整策略这条链路必须闭环至少在处理常见情况时可以闭环。第三Agent 必须具备失败降级能力。它不能做一件事做不通就整个人卡住它要能判断“这一步我搞不定”然后要么换一条路径要么给你返回一个明确的失败原因并且告诉你哪些部分是可恢复的。这三条标准看起来很朴素但一旦对照这三条去审视绝大多数“Agent 框架”你会发现它们只是提供了“让模型调用工具”的脚手架并没有替你解决“怎么把一个任务从模糊推进到验收状态”的问题。也就是说框架能给你的是胳膊腿但“让胳膊腿按正确顺序配合起来把活干完”这件事还是得自己设计。所以第二天的重构我们没有陷在 prompt 调优里而是围绕着三条线重新组织代码任务分解与状态机、工作产物管理、以及与工具交互时的故障处理。接下来我会一条一条讲因为这三块里藏着“为什么很多 Agent 项目活不起来”的真正答案。2.1 记忆的真正职责是支持“工作流畅性”而不是炫耀“它记住你了”如果只看宣传海报很多人会觉得 Agent 的记忆应该像人一样记得你的偏好、记得你上次聊到哪、记得你三个月前说过什么。这些当然有意义但对“开工”这件事来说记忆的核心作用只有一个字顺。什么叫顺举个例子。如果你让 Agent 去整理你本周的所有会议纪要它的工作流程需要涉及好几个步骤读取日历、识别会议事件、定位对应录音或者笔记文件、提取关键结论、生成汇总文档。在这个流程中它需要反复使用“哪些会议是本周的”“哪条录音是这场的”“这个人上次提的结论是什么”这些信息。如果每一轮任务执行都要重新翻一遍日历和文件、或者从无到有地重新理解上下文这个 Agent 会慢得让人觉得它根本不像一个干活的人。所以我们把记忆分成了两层。第一层叫调度记忆只存“当前任务上下文里必须反复引用的状态变量”——比如当前任务 ID、当前阶段、已经产出的中间产物路径、正在对接的外部工具返回结果。这一层是短暂的、结构化的用内存对象管理不走向量数据库。第二层叫项目档案记忆按项目维度存储跨会话的稳定信息比如“这个项目的报告模板偏好是什么”“上次总结写到哪个版本”“客户那边的联系人习惯用什么沟通方式”。这一层才落到持久化存储里。这么做最大的好处是Agent 在单次任务中不会频繁地被“记忆读取”打断因为它每个步骤要什么上下文早已在调度记忆里被显式传入了。这种“显式传入”的做法比让模型自己去向量库里模糊检索高效得多而且极大地减少了模型“自作主张回忆但回忆错了”的情况。2.2 我们不做的把“长期记忆”当成 Agent 的能力底座这件事可能跟很多人的直觉相反。我们最早版本也试过把“记忆”做成核心对话内容全量写入向量库每次任务开始前先把相关记忆检索出来拼到 prompt 里。这套路看起来很美但实际跑下来的问题非常多。首先是污染问题。一旦向量库里存了过多不一致的信息比如上周你说“这个项目用 A 方案”这周你又说“改用 B 方案”检索出来的结果可能同时包含 A 和 B模型就会开始犹豫甚至把两条信息并列输出。你以为你在给 Agent“增加记忆”实际你在给它“增加噪音”。其次是成本膨胀。每次任务都带着一大坨检索出来的记忆token 消耗会肉眼可见地增长模型为了在这些历史信息里“找线索”反而忽略了当前任务真正需要的操作指令。到了第三天我们统计的时候发现启用全量记忆后的单任务成本比关闭记忆高了三倍但任务成功率没有显著提升。所以最后我们定下来的原则是记忆要服务于任务的“必要上下文”而不是服务于“让模型感觉更懂我”。也就是说我们宁可在任务开始时把需要用到的字段显式写成一个 JSON 传给模型也不让模型自己去历史对话里猜。必要的信息结构化和高频访问绝对优先于面面俱到的历史记录。这个决策可以说是整个项目里最关键的一个转折点。从这一刻开始Agent 的设计重心从“让它知道得多”变成了“让它用得准”。2.3 记忆接口设计用“项目档案”而非“对话流水”作为持久层单位具体到实现上我们放弃了传统的“会话 向量库”模式改成了一套更接近工程实践的项目档案结构。每个长期任务对应一个目录目录下有一个project.json里面记录任务目标、当前状态、关键决策、已迭代的版本记录、以及一组“执行字段”。执行字段是给 Agent 下一步动作用的比如数据源文件路径、报告模板路径、上次运行到哪一步、下一次应从哪个阶段继续这些字段由代码逻辑维护Agent 本身不能任意改写只能通过特定工具去更新。这个设计的经典之处在于模型不再需要拥有“修改记忆的自由意志”。它想更新项目状态必须调用一个update_project_field工具这个工具会校验字段名是否在白名单里、值格式是否符合类型约束。一旦通过状态变更才会被记录。这就在工程层面杜绝了“模型自己脑补了一段历史然后当成事实存进去”的情况。这套结构跑通后我们明显感觉到 Agent 的稳定性上了一个台阶。因为它不再依赖模糊检索它要么在调度记忆里找到准确的中间变量要么通过明确调用工具去项目档案里更新信息。它不会出现“我记得你说过 X所以我这样干”这种难以追查的行为。3.1 我们最终选择的实现路径harness 模式而非“自由 Agent”模式接下来聊聊核心架构。当我们说“Agent 开工”的时候代码里的实际形态其实更像一个严格约束的执行环境而不是一个让模型自主决策的“自由人”。如果你了解 Claude 的 Agent 开发方式你可能听说过 harness 和 agent 这两个概念的区别。这里我想说我们的经验是要让 Agent 能真正用于工作你必须自己构建一个 harness而不是放一个裸的 agent 让它去折腾。用大白话解释 harness 和 agent 的区别agent 是“大脑”它负责理解自然语言、做判断、选择行动但大脑本身不会干活它需要手、脚、眼睛。而 harness 就是把这些“手、脚、眼睛”和大脑组织起来的一套闭环控制系统。它会定义每一步动作的输入输出格式、允许调用哪些工具、工具返回结果后下一步怎么走、以及失败时怎么退回。没有 harness 的 agent就像一个只有大脑但没有四肢协调能力的病人它什么都知道但什么都做不成。市面上很多 Agent 框架给的其实是 agent 层的抽象比如定义 tool list、自动让模型调用。但一旦任务复杂起来光有 agent 而不控制它的操作序列它就会开始“自由发挥”。你让它查资料它去调了十个搜索 API你让它写文件它写到一半停下来问你“要不要继续”。所以我们用 harness 的思路把所有工具调用都封装成了一步一校验的流程。模型只能按流程申请调用流程会检查参数、检查前置条件然后执行动作最后检查返回结果是否正常。模型本身并不直接接触文件系统、网络请求这些底层操作。3.2 Skill 与 Agent 的正确边界不能让模型“自由组合技能”还有一个很容易踩的坑就是 skill 和 agent 的关系。简单说skill 是一个可复用的干活的步骤模板agent 是决定“要不要用这个模板、怎么套用这个模板”的决策者。但很多项目做反了它们把一堆 skill 描述塞给模型让模型自己自由组合结果模型经常把不相关的 skill 编排在一起产出四不像的结果。我们的做法是把 skill 定义得足够不规则化一个 skill 必须同时包含触发条件、执行步骤、输入输出 schema、以及验收标准。模型不能凭空选择使用哪个 skill而是由一个路由模块——本质上是一个规则引擎加少量分类模型——根据当前任务类型决定启用哪个 skill。这个路由模块是代码写死的不是模型现场开脑洞的。举个例子我们有一个“撰写分析型文档”的 skill它的执行步骤是固定的收集材料 – 制作提纲 – 生成初稿 – 自查证据 – 输出终稿。每一步都有单独的 prompt 和校验函数。模型能做的是在每一步里填充内容、调整措辞但不能调换步骤顺序也不能跳过“证据自查”直接输出终稿。这么做看似限制了模型的自由实际上是真正的“为了干活好”。因为验收标准在每个 skill 里已经写死了模型知道自己到底要做到什么程度才算完成而不是模模糊糊地做到“看起来差不多”。我们把当时对比过的两种模式整理如下表设计模式模型的自由度结果可控性适合场景自由 tool calling高模型可任意选工具低容易组合出无意义流程简单单轮任务skill 模板 路由中模型只能在步骤内创作高每步有验收标准多步骤、可交付物明确的任务全代码编排低仅调用模型做局部生成极高业务确定性最强流程固定、重复性高的任务可以看到我们最终站到了中间和偏左的位置。并不是说自由 tool calling 完全没有价值而是在个人助理这种需要持续产出真实成果的场景里可控性远比自由度重要。3.3 状态机与检查点让 Agent 具备“做到哪算到哪”的工程底座要让 Agent 具备“干活干到一半也能停下来下次还能接着干”的能力必须在架构层引入状态机和检查点。这块算是我个人认为最容易忽略、但价值回报最直接的一个设计。我们把任务展开成一棵树树的根节点是用户提交的原始目标一级子节点是阶段二级子节点是具体动作。每个动作执行前会把当前状态序列化成一个检查点存到本地工作目录。一旦动作失败Agent 可以回滚到最近一个检查点重新执行而不是整个任务从零开始。更重要的是检查点会记录“这个阶段已经完成了几步、还差几步、中间产物在哪”。这样即使外部工具断了、模型调用超时、甚至 Agent 进程被重启它也能从检查点恢复继续推进任务。我们在测试中最极端的一种情况是任务执行到第四步时网络彻底断掉网页搜索全部失败。原本以为整个任务会废掉但因为检查点机制Agent 在恢复网络后直接从第三步重试最终依然完整地产出了目标文件。这个机制看起来不复杂但绝大多数开源 Agent 项目是没有的。它们一般是单轮 prompt 满天飞没有本地任务状态的概念。一旦中途出现意外整个上下文就废掉了。这里我可以直接说如果你想做一个“能开工”的 Agent检查点和状态机绝对值得优先投入时间实现。4.1 为什么“看起来聪明”的 Agent 一上真实任务就露馅问题出在验证环节缺失聊完架构层面的设计下面说说为什么很多 Agent Demo 看起来文采飞扬但一上真实任务就肉眼可见地拉胯。我观察到最主要的原因是验证环节的缺失。你可以回想一下常见的 Agent 演示视频模型读了一段资料然后输出一段总结主持人说“哇它真的会总结”。但注意演示里没有人去检查这段总结是否覆盖了原文所有关键信息、是否遗漏了某个数据点、结论是否基于证据。这一点才是真实工作中最要命的如果 Agent 输出的产物带着未知的错误进入下游流程造成的破坏可能比完全没有 Agent 更大。我们在项目中用了一个很简单的策略来解决这件事在每个 skill 的最后一步强制加入“验证动作”。验证动作不是一个单独 prompt 让模型自己检查自己而是要调用可执行的代码逻辑去检查产物结构是否完整。举例来说如果最终产物是一份 markdown 报告验证函数会检查是否有 H1 标题、是否有至少三个 H2 章节、每个章节是否超过 50 字、是否包含关键词对照表、引用的数据是否都在参考资料中出现过。这些条件全部通过报告才算“可交付”。这个“硬验证”思路直接把 Agent 的输出从“语言上成立”拉到了“工程上可用”的层级。它不再是“你读着感觉挺行”而是“程序判定它行你才有资格看它行在哪里”。4.2 失败的降级路径设计当 Agent 实在搞不定时它可以承认错误很多第一次构建 Agent 的人最怕的一点是Agent 卡住了怎么办。我在开源社区里看了一圈绝大多数项目对这个问题的回答是“重新让模型生成一次”或者“换一个更强的大模型”。如果一个 Agent 真的做不了当前步骤它死活不告诉你“我失败了”而是重复尝试同一个错误路径这会导致非常严重的资源浪费。我们为所有工具调用设置了两个层级的降级第一层是重试降级比如数据库查询失败、接口返回超时代码会自动重试最多三次超过三次后进入第二层。第二层是策略降级模型可以在这一步选择“更换备选工具”或者“请求用户输入以消除歧义”或者“将当前子任务标记为失败并把失败原因记录到项目档案中”。一旦某个子任务被标记失败Agent 会重新评估整个任务树这个失败是否影响最终交付如果影响它要明确告诉用户“这个任务不能完整交付因为某个关键依赖缺失”而不是写一份妥协版的报告并假装它没问题。这套机制听起来简单但实际执行起来对模型的要求其实很高。因为我们发现默认情况下大模型非常不愿意在任务中途承认自己不行。它宁可硬编一个答案也不愿意承认“此处需要用户提供更多信息”。所以我们后来加了一个特殊的系统提示词明确告诉模型如果你的选项中包含“无法完成”那么选择“无法完成”是合法的并不会被扣分相反硬编一个不可靠的答案才会被视为重大错误。加上这个提示之后Agent 的安全感和行为可靠性都明显提升。这是一个非常反直觉的经验你越允许模型说“做不到”它反而越能把真正能做到的事情做得更稳。4.3 超时、令牌耗尽与不死循环必须用代码干预的三个工程死角即便有了好的降级路径Agent 在真实环境中还是会碰到一堆不过代码就无法干预的工程死角。这三天里我们在这些部分调试的时间加起来有七八个小时因为它们不像模型效果那么直观但缺了它们整个系统根本无法稳定运行。第一个死角是单步执行超时。模型调用外部 API 也好、生成超长文本也好都可能出现“响应时间无限拉长”的情况。我们在 harness 层给每个动作都设置了最长允许时间超时立即中断。这个时候如果放着一个 Agent 自己干等它可能会挂机几个小时。中断后按前面的检查点机制回滚至少能保证系统不会卡死。第二个死角是大模型输出长度限制。当调用模型生成长篇报告时输出经常超过 API 单次返回的最大额度。如果不管模型会直接截断而且截断的部分看起来像正常结束很难判断。我们在这块的处理是在调用模型前就先规划好内容分段。系统一次性生成完整报告的骨架然后每次只让模型补一小节再循环执行直至全部完成。虽然这增加了调用频次但显著避免了截断产生的残缺报告。第三个死角是工具死循环。这个最隐蔽初始时把我们坑惨了。模型在一个动作失败后可能因为提示词不够清晰开始循环尝试同一个调用每次返回同样的错误。我们一开始以为大模型总会从错误中学习结果发现它们有时候会陷入机械重复尤其当 prompt 里存在“如果失败就再试一次”这样的话时。最终的解决方案是在 harness 里增加重复动作计数器同一动作连续失败超过三次就强制切换到降级路径或者上报失败原因无论如何不让它无限循环下去。这三个死角没有一个是模型能力层面的问题全部是代码层面的工程问题。如果你只跑一个单轮 Demo可能根本遇不到它们但一旦让 Agent 全天候自主跑任务它们就会像蚂蚁一样爬满整个系统。绕开它们的唯一办法就是在设计 harness 时就把这些边界条件当成一等公民对待。5.1 用 Evals 而不是“肉眼观察”来验收 Agent 的能力提升做完架构重构、工具封装、状态机与超时控制之后我们的 Agent 已经可以在技术上跑起来了。但这里冒出一个新问题怎么证明它真的“能开工”团队里出现了分歧。有人说用几个测试用例演示一下录个屏看起来流畅就行。但我坚持要用 Evals——也就是一组合法的评估用例集——来量化地验证 Agent 的能力是否真实达标。如果你不熟悉 Evals可以把它理解成 Agent 的单元测试。我们把个人助理要覆盖的应用场景拆成大约 40 个任务场景每个场景都对应一个明确的输入、一组受限的工具集、以及一个可计分的最终输出。比如对“整理本周会议纪要”这个场景输入是日历文件和一个笔记目录工具集是日历解析、笔记读取、文件写入三个工具评分标准是“是否生成了汇总文档、文档是否包含所有会议时间与结论、是否有明显遗漏或错误”。每个场景跑完后会自动给出一个 0 到 100 的分数。这个评估系统的价值在重构过程中立刻体现出来了。第一天重构完成时我们的 Agent 在 40 个场景里的平均分只有 41 分很多任务直接中途卡死。我当时有点失望但这也给了我一个精确的“施工地图”。接下来两天我们根据失败案例一个个修。到第三天结束时平均分涨到了 79 分。而更让人高兴的是原本最弱的“多轮跨步骤任务”场景从 17 分涨到了 68 分这意味着 Agent 已经能真正自主地做复杂流程了。没有 Evals 的话我觉得我们大概率会被 Demo 的流畅表现骗过去觉得自己做得不错然后交付一个一上真实场景就崩掉的东西。而现在我至少可以说在定义的 40 个场景里接近 80% 的任务它都能干到可交付状态。这份“可量化的自信”才是我们应该追求的东西。5.2 常见评估陷阱为什么“多轮对话成功率”不能反映真实工作能力聊到 Evals就不得不提一口大坑很多团队的评估指标放在“多轮对话成功率”上。这个指标表面上好像跟 Agent 能力有关但实际会严重高估系统的真实可用性。解释一下原因多轮对话成功率衡量的是“模型在每个回复轮次里是否给出了合理的回答”。但“合理的回答”和“成功完成任务”之间隔得很远。比如用户问“帮我查一下竞品A最近改版了哪些功能”Agent 回了一句话“好的我来搜索一下相关信息”这一轮对话就算成功了但实际上它可能并没有真正执行搜索也没有返回任何经过验证的结论。多轮对话成功率会把这个过程判定为“成功一轮”而真实工作任务里这个过程等于什么都没干。我们设计 Evals 时刻意把所有分数都绑定在最终可验证的交付物上而不是绑定在模型回复文本是否自然上。只有当文件被生成、表格被填充、数据库被更新、并且验证脚本通过了这一个 case 才算通过。哪怕 Agent 在过程中说了几句怪话、转了个弯、问了用户几个问题只要最终交付物合格它照样能拿到高分。反过来哪怕它每一轮回复都极其优美只要没产出有效交付物这个 case 就是零分。这套评估体系彻底改变了团队的思考方式。我们不再关注“模型回答得顺不顺”而只关注“任务做没做完、做没做对”。这也是偏向个人助理用途的 Agent 最该有的验收标准。5.3 三个值得优先构建的评估场景路由、工具选择与失败恢复如果你的 Agent 项目刚开始我建议不用一口气构建 40 个场景那样太耗时间。你可以先把三类最关键的能力评估出来它们基本上覆盖了“是否能开工”的核心风险。第一类是你的“任务路由能力”。给 Agent 一组输入有些适合直接调用某个 skill有些需要跨 skill 协作有些完全超出能力范围。评分标准就是它能不能把输入正确分发到对应的 skill 路径上。第二类是“工具选择能力”。面对一个子任务工具列表里有多个可选项有的明显正确有的是干扰项。评分标准是它是否每次都能选中最合适的工具而不是乱试。第三类是“失败恢复能力”。人为让某个工具返回错误或者注入一段伪造的中间结果看 Agent 是否能检测到异常、是否走降级路径、是否能最终完成任务。这三类场景不大但能非常有效地暴露一个 Agent 架构的薄弱点。我们最终保留的核心评估集也正是这三类的组合外加一些贴近业务场景的集成用例。后续扩展场景时基本也是围绕这三个维度去叠加。这套评估方法论我认为可以长期复用——即使你后续换了底层大模型换了工具集只要你想验证“Agent 到底能不能开工”这三类评估永远都是第一道关卡。6.1 我们为什么要坚持“人机边界清晰”允许 Agent 拒绝但必须给出解释写完评估方法之后回到我们最初的问题什么是“真正开工”的核心感受我觉得是一套关于边界的清晰认知。这里的边界不仅指技术边界更多是“人机协作的行为边界”。我们在测试中发现如果 Agent 对一切指令都无条件执行看起来很“听话”但用户反而很难信任它。因为它什么都说“好的”让人无法判断哪些话是真的、哪些又是它为了让用户满意而编出来的。因此我们在系统里增加了一个明确的“拒绝与请求澄清”机制。当 Agent 认为用户指令里包含不明确的关键条件时它可以直接输出一条结构化请求说明“我无法在以下条件不明确的情况下安全执行该任务请确认 X 和 Y”。这种方式不是消极罢工而是主动把不确定性暴露出来。用户看到之后会立刻明白哪些地方需要补充Agent 也不会因为猜测错了而白白浪费大量 token。这个机制在个人助理场景里尤其重要。因为用户往往抱着“你替我搞定一切”的心态来使用 Agent如果 Agent 不问青红皂白地把一切假设都做成“不存在的既定事实”那产出物的真实性就值得怀疑了。所以我们的设计哲学是允许 Agent 说“不能做”但它必须同时告诉我们为什么不能做、以及需要什么信息才能做。这样一来每一个“拒绝”其实都是在教用户如何更好地使用它。6.2 如果把个人 Agent 接入真实工作流必须先完成的三个基础设施最后提一个实际切入真实工作流的建议。如果你的个人 Agent 已经在一个沙盒环境里跑得风生水起想真正把它接到日常工作流程里去我强烈建议你先完成三件事否则后续的“翻车”会让你怀疑人生。第一件是文件版本管理。Agent 会持续生成中间产物、修改最终文件。如果没有版本控制一次错误操作可能把好端端的文件覆盖得面目全非。我们三天里最惨痛的一次教训就是Agent 把一份原本 80 分的报告覆盖成了一份 40 分的版本而且没有留下旧版备份。后来我们给 Agent 的工作目录接上了本地的版本管理工具每次写入文件都自动提交一次快照这才让回滚变得可靠。第二件是完整的运行日志。Agent 每完成一个动作都要在日志里记录输入、输出、消耗的 token、耗时、是否校验通过。没有这套日志你根本没法制Debug。我们经常是看到 Agent 最终产物不对连接着翻前面的日志才能定位是哪个环节出了问题。而且日志不仅是为排错准备它还能帮你持续优化 Agent每天统计一下动作失败率、工具调用失败率、token 消耗分布你就知道下一步应该优化哪个环节。第三件就是退出机制。你必须确保无论什么时候用户都可以一键终止 Agent 当前正在执行的任务。我们一开始没有把这个做深结果有一次 Agent 在一个子任务里卡了循环我们只能通过杀进程来终结它。后来我们在系统里加入了显式的中断命令用户在任何对话框里输入“停止当前任务”Agent 就会立即执行代码级的中断、保存当前状态然后进入等待状态。这种安全阀对你实际使用 Agent 的信心提升是非常巨大的。这三件事看起来一点都不“AI”但它们恰恰决定了 Agent 能不能从演示项目变成一个你能放心交活的生产工具。6.3 关于“真正开工”这件事我的最终体会回到标题里那句“我不想再做一个记忆型 AI”。经历了这三天的折腾我对这句话有了更深的理解。所谓“记忆型 AI”不只是说它没有工作能力而是说它的整个逻辑框架都建立在“语言生成”这一件事上。语言生成当然很重要但它不是工作本身。工作意味着要管理任务状态、要操作真实文件、要处理失败、要产出可验证的结果。现在再回头看我们最早那个能记上下文、能调工具的 Demo我会说那只是 Agent 的起点不是 Agent 的完成态。真正让它开始创造价值的地方恰恰是我们从第二天开始做的那些“看起来像传统软件工程”的事情状态机、检查点、Evals、超时控制、版本管理。它们不洋气但它们把 Agent 从“会说话的模型”变成了“能干事的系统”。如果你也在做一个类似的 Agent 项目我的建议很直接第一别急着上记忆先设计任务状态第二别指望模型自己搞定一切亲手写 harness第三别靠肉眼验证能力用 Evals 建立你的信任度。这三天我们踩过的坑应该能帮你省下不少时间。