第26章 持续进化的生活 Agent：从日常反馈到可信能力闭环

前面的章节讨论了如何构建一个能够调用工具、管理知识和完成多步任务的 Agent。但一个真正进入日常生活的 Agent 面对的不是一次性 benchmark，而是长期、变化且高度私密的环境：今天的日历安排、反复修改的待办、被拒绝的邮件草稿，以及每个人不同的工作和家庭节奏。

这类系统最容易犯的错误，是把“记住了一次反馈”误当成“已经学会”。把一条对话直接写入长期记忆，或立即改写 Prompt，看似能让下一次表现更好，却会把偶然偏好、错误归因和敏感数据一起固化。持续进化应当是一条受控的软件交付链路：运行证据 → 评估 → 更新提案 → 独立验证 → 审阅 → 渐进发布或回滚。

本章以“每周生活回顾 Agent”为例，说明如何把日历、待办、邮件、购物清单和个人知识组织成一个可长期运行、可审计、可撤销的系统。这里的“生活”不代表无限授权：Agent 可以准备建议和草稿；任何发送、购买、支付、删除或涉及健康、金融的动作，都必须保留给明确的用户确认。

26.1 长期运行的生活 Agent：范围、授权与非目标

生活 Agent 的目标不是替用户接管生活，而是降低整理信息、发现遗漏和准备行动的成本。一个合适的最小闭环是：汇总一周事实，提出下周建议，收集用户对建议的修订，再将可复用的改进作为候选变更提交评估。

三层权限，而不是一个“自动执行”开关

同一项能力应按风险拆成三个层级：

“帮我处理一下”不是外部动作的授权。系统应在动作前展示对象、影响范围、关键参数和撤销方式；对支付、购买、医疗建议、投资与金融交易，默认只提供信息整理或建议，不替用户执行决策。

长期运行带来的四个边界

1. 最小权限：只申请完成当前任务所需的日历、邮件或清单范围；不因“未来可能有用”扩大访问。
2. 目的限定：为周回顾收集的会议标题，不应自动用于训练通用写作风格或分享给其他 Agent。
3. 可见与可删除：用户能看到 Agent 保存了什么经验、为什么保存，以及如何更正或删除。
4. 不把沉默当同意：没有点击建议、没有修改草稿，均不是可推广的偏好信号。

这些边界是 第11章 Harness 工程 中权限、状态和恢复控制在个人场景的具体化。它们先于“让 Agent 更聪明”的目标。

记忆、日志与学习的区别

• 日志记录发生过什么，服务审计、排障和复盘；原始记录应不可变。
• 记忆保存经用户确认或可解释的稳定事实、偏好和上下文，服务后续个性化。
• 学习改变未来策略、Skill、工作流或 Harness，必须证明它对一组任务有效且没有破坏既有成功场景。

因此，一句“我不喜欢早上安排深度工作”可以作为待确认的偏好候选；只有经过多次确认、存在来源与有效期后，才可能成为记忆。它更不应该直接变成一条全局 Prompt 规则。

26.2 以证据为先的运行数据模型

受控进化的输入不是“模型的印象”，而是带边界的运行证据。每次执行都保留一个不可变轨迹，并在其上生成可审阅的经验卡。轨迹保留事实，经验卡表达可被反驳的假设；两者都不能绕过用户的删除与保留期策略。

原始轨迹：让一次结果可以重放

一条最小轨迹至少包含：任务触发条件、被允许使用的上下文快照、模型与 Prompt/Skill 版本、工具调用与返回、用户确认点、最终结果和反馈。它与 第10章 Context 工程 的证据和状态边界相呼应：复盘时不能只看最终回答，还要能解释 Agent 当时看到了什么。

{
  "run_id": "weekly-review-2026w34",
  "task": "生成下周生活回顾建议",
  "context_snapshot": ["calendar:week-34", "tasks:open", "shopping:pending"],
  "versions": {"model": "approved-model", "skill": "weekly-review@1.3"},
  "tool_events": ["calendar.list", "tasks.list", "shopping.list"],
  "result": "提出 4 条建议，未执行外部动作",
  "user_feedback": "接受 2 条、修订 1 条、拒绝 1 条",
  "retention": "30d",
  "sensitivity": "personal"
}

示例中的标识符只是演示数据；生产系统应将内容与敏感等级分离存储，对原文进行访问控制、脱敏和按期删除。

经验卡：从轨迹中提出、而非宣告规律

经验卡是对多次轨迹的结构化分析，不是新的事实源。它需要同时记录支持证据和反证：

例如，“周回顾遗漏了购物清单中的临期商品”不是直接修改规则的理由。只有在多条轨迹表明清单读取成功、但汇总 Skill 稳定漏掉日期字段时，才形成“将日期字段加入检查表”的 Skill 更新候选。

26.3 三层评估：结果、过程与质量验证

生活任务的正确性通常不能只由模型自评。一次建议看起来通顺，不代表它节省了时间、正确使用了工具或尊重了权限。评估应分为结果、过程和质量三层，并把用户反馈作为证据的一部分而非唯一裁判。

反馈应先归因，再参与学习

用户将“周三下午”改成“周四上午”，可能代表偏好，也可能只是那一周的临时冲突。系统需要把反馈分层：

• 显式反馈：接受、拒绝、评分、填写原因；证据最强。
• 隐式修订：用户改写草稿、移动建议任务；需要结合上下文解释。
• 自动校验：日期是否存在、重复事件是否冲突、工具返回是否完整；能验证事实但不能推断偏好。

把这三类信号统一写成“用户不喜欢周三”会产生错误的长期记忆。应该先在经验卡中保留不确定性，再由跨轨迹分析决定是否提出变更。

留出集防止“只修好一次失败”

每个更新候选至少要经过两类任务：

1. 触发集：确实暴露问题的历史轨迹，用来验证提案解决了原始失败；
2. 留出集：未参与规则设计的历史任务，覆盖已成功的日程整理、草稿生成和权限确认场景，用来发现回归。

这把 第17章 Agent 生产治理 的 Evals 从“上线前测一次”延伸为每次能力更新的门禁。只有触发集改善、留出集不退化、权限检查仍完整的提案，才进入审阅。

26.4 更新路由：知识、Prompt/Skill、工作流与 Harness

同一种失败不应由同一种手段修复。将所有经验都塞入记忆，会让检索噪声变大；把所有问题写进 Prompt，会形成难以审计的指令堆；把权限问题交给工作流，也会遗漏运行时的硬约束。更新路由的作用，是把证据送往正确的工程层。

知识与记忆：有来源、可失效、可撤回

第14章知识系统 适合承载带来源的事实，第15章记忆 适合承载经确认的个体化信息。两者都需要版本、来源、敏感等级和失效策略。对于“本周临时改为晚间购物”这类信息，应设置短保留期；对于“不要把工作会议安排在家长会时间”这类长期偏好，也应能被用户一键撤回。

Prompt 与 Skill：最小差异，而不是不断追加

Skill 更新应像代码改动一样小、可定位：说明失败边界、只修改必要步骤、以触发集和留出集验证。比如把“检查日历”改为“读取可用时段和已有的不可移动事件”，比追加一段笼统的“请更仔细检查”更可测。

工具使用和 Skill 契约应保持与 第13章工具、Skills 与 MCP 一致：输入、权限、超时、失败语义和输出格式必须明确。经验卡不能绕过这些契约去产生隐式工具调用。

工作流与 Harness：把重复步骤和硬约束放在模型外

若失败表现为固定的多步遗漏，应将其编译为工作流，并为每一步定义前置条件、动作和后置验证。例如，只有在日历与待办快照均完整时，才允许生成周计划；生成后必须检查建议是否占用已有不可移动事件。编排细节可回看 第16章工作流编排。

若失败涉及权限、重试、并发、取消、审计或回滚，则应由 Harness 修复。模型可以提出建议，但不能移除确认门、扩大 token 或工具权限预算，或绕过事件日志。

26.5 受控发布闭环

持续进化不是在生产环境中让 Agent 随意自我修改。更可靠的流程类似一次小型发布：

运行轨迹与反馈
        ↓
跨轨迹证据聚合与经验卡
        ↓
知识 / Skill / 工作流 / Harness 更新提案
        ↓
触发集 + 留出集回归 + 安全检查
        ↓
人工审阅与版本记录
        ↓
小范围试运行 ──失败──→ 回滚到上一个已批准版本
        ↓
正式发布与持续观测

提案必须能回答的六个问题

在任何改动进入试运行前，提案至少需要写清：

1. 它由哪些轨迹触发，反证是什么？
2. 它改变哪一层能力，为什么不是其他层？
3. 它的最小 diff 是什么，影响哪些任务边界？
4. 触发集、留出集和安全检查的结果如何？
5. 谁能批准、试运行对象是什么、何时停止？
6. 出现何种指标退化时回滚，回滚到哪个版本？

人工审阅与渐进发布

人工审阅不是逐句审核模型输出，而是审核能力变化的证据和风险。对只影响“建议”层的低风险 Skill，可以先在只读模式下对一小段历史任务重放；对“草稿”层变更，可先向少量用户展示新旧建议；任何涉及外部动作的变更，都必须重新确认权限与动作预览。

发布记录至少包含版本号、变更摘要、评估结果、审阅人、试运行范围、指标与回滚条件。这样，当用户发现“新版本总把购物提醒放到工作时间”时，可以定位到具体变更，而不是在不可见的记忆里猜测原因。

26.6 案例：每周生活回顾 Agent

下面用一个不接入真实账号的模拟案例串联全流程。每周日，Agent 读取经授权的日历、待办、邮件摘要和购物清单，生成下周建议；它不会发送邮件或创建支付订单。

第一步：形成只读回顾

输入：日历快照、未完成待办、用户标注的邮件摘要、购物清单
输出：冲突提示、待办聚类、可选安排、待确认的邮件草稿
禁止：发送、购买、支付、删除、修改原始日历事件

输出中的每条建议要能追溯到数据来源。例如“将报销安排在周四上午”应列出未完成任务、可用时段和冲突检查结果，而不是只给一个无来源结论。

第二步：采集反馈并生成经验卡

假设用户连续三周都把“整理购物清单”的建议移到晚间。系统不立即写入“晚间购物”的永久偏好，而是生成一张候选经验卡：

假设：当工作日白天已有连续会议时，用户更愿意在晚间处理购物清单。
证据：3 条接受后移动的周回顾轨迹。
反证：1 条周末白天完成购物的轨迹。
候选更新：周回顾 Skill 增加“优先选择非连续会议后的可用时段”。
验证：4 条触发集 + 12 条未参与设计的留出集。
权限：建议层；不创建日历事件。

这张卡保留了反证和适用边界，因此不会把“某几周的繁忙状态”错误泛化为永久习惯。

第三步：路由、验证与发布

如果用户明确说“工作日白天不要安排购物”，可更新为有来源、可撤回的偏好记忆；如果只是周回顾遗漏了可用时段，则更新 Skill；如果每次都要读多个工具再做冲突检查，则把步骤编入工作流；如果建议错误地越过了“不可创建事件”边界，则修复 Harness。

对候选 Skill 的验证可按以下顺序进行：

1. 在触发集上确认遗漏减少；
2. 在留出集上确认会议冲突、建议数量和用户修订率没有恶化；
3. 检查所有外部动作仍停在确认门前；
4. 由用户或指定审阅者批准后，以只读建议模式试运行；
5. 若人工接管率或越权拦截率超过阈值，立即回滚至上一个已批准版本。

这个案例与 第25章个人知识管理 Agent 的关系是递进的：第 25 章解决“如何组织个人知识”，本章解决“如何让围绕这些知识运行的 Agent 在长期反馈中保持可信”。

26.7 上线检查清单与度量

在把“会进化”作为卖点前，先回答下面的检查清单：

• 是否区分了原始轨迹、经确认的记忆和待验证的学习提案？
• 每项提案是否有来源、反证、适用边界、保留期与撤销方式？
• 是否为建议、草稿、外部动作分别设置了权限和确认点？
• 是否使用了独立的留出集，而不是只观察触发问题是否消失？
• 是否记录了版本、审阅人、试运行范围、阈值与回滚入口？
• 用户是否可以查看、修订和删除与自己相关的经验和偏好？

建议从以下指标开始观测，而不是追求单一“智能度”分数：

持续进化的终点不是让 Agent 获得无限自主权，而是让它在有限授权内更稳定地完成工作，并且在出错时能够解释、停止、修复和恢复。把这条闭环做好，生活 Agent 才能从一次性助手变成值得长期信任的伙伴。

参考与延伸阅读

• 第10章 Context 工程
• 第11章 Harness 工程
• 第13章 工具、Skills 与 MCP
• 第14章 Agent 知识系统
• 第15章 Agent Memory
• 第16章 工作流编排
• 第17章 Agent 生产治理
• 第25章 个人知识管理 Agent 实践
• AI Agent Book，第 9 章：持续进化