Agent 记忆与可验证自我改进怎么设计
微信公众号「架构师（JiaGouX）」作者若飞 2026-07-19 推送。本文把 Agent Memory 从“存历史”推进为“经验变更系统”：核心不在记得多，而在什么经验何时能影响未来。
正文
做 Agent 记忆，我现在最担心的已经不是它忘了什么。
更麻烦的是，它记住了一条并不可靠的经验，后面每次都照着做。
比如，一个自动修 CI 的 Agent 遇到测试超时，把等待时间从 30 秒调到 90 秒，测试绿了。系统把这次处理写进长期记忆。几周后，同一组测试再次失败，Agent 取回旧经验，又去调大超时，还顺手把重试次数写进了 Harness。
可这一次，根因是依赖升级。
Agent 没有忘记。它记得很快，也学得很快，只是把一次偶然有效的处理，慢慢变成了默认做法。
这类事在研发之外也很常见。Pod 被
OOMKilled
后，重启能恢复服务；把它写成“出问题就重启”的自愈策略，风险就大了。接口加一层缓存，P99 延迟下来了；照搬到所有慢接口，又可能带来一致性和回源问题。暴雨天绕路快了十分钟，也只说明那天那条路更合适。
这一刻有效，只能说明结果变好了。根因是什么、适用于哪些条件、下次是否还成立，还得继续查。
我们之前梳理 Agent Memory 时，重点是“过去的信息凭什么影响未来”。走到 Self-Harness 和持续学习这一步，问题又多了一层：
一段过去要经过什么，才有资格修改未来的运行方式？
我的看法是，
生产级 Agent Memory 更适合按“经验变更系统”来设计。它不只负责保存和检索，还要管理证据、状态、作用域、验证、晋升和回滚。
沿着这条线看，可验证自我改进也没那么玄。它要解决的，是一次运行结果怎样从“发生过”，逐步变成“以后可以照着做”。
一次有效，离可靠经验还很远
•
记忆一旦参与决策
，就不再只是存档。它在给历史分配未来影响力。
• 原始证据、当前状态、候选经验、已验证记忆、Skill/Harness 和 Policy 是不同资产，
不能都塞进一个
memory
字段
。
• 记忆读取要回答两件事：
当前任务要不要用历史，取回来的又是哪一版历史
。
• 一次成功先记成观察。能复现、有外部证据、作用域清楚，才有资格晋升为长期经验。
• Memory 进入 Skill 或 Harness，意味着“参考信息”开始变成“默认行为”，验证要求也要随之提高。
• Agent 可以生成候选、分析失败、运行实验。
评估器、权限、评估集、晋升和回滚
放在另一个信任域会更稳。
图 1：Agent 经验变更系统，由读取链、写入链和控制面共同约束
记忆一旦参与决策，就不再只是存档
很多团队第一次做 Agent Memory，会从数据库和向量检索开始。
存对话摘要、用户偏好、历史任务，再按相似度取
top-k
，拼回上下文。这个版本能跑，也能解决一部分连续性问题。
可一旦 Memory 会影响工具选择、代码修改、任务计划和权限申请，问题就变了。
系统需要知道：
• 这条信息来自用户、工具、代码仓库，还是 Agent 自己的推断；
• 它描述的是当前事实、历史事实，还是一次状态变化；
• 它在哪个用户、项目、版本和任务类型里有效；
• 它是否经过验证，谁做的验证；
• 它什么时候过期，被哪条新记录替代；
• 用错以后，怎样找到影响链并撤回。
这些都不是存储引擎能独立回答的。
《
Agent Memory 架构解析：过去的信息，凭什么影响未来
？》里，我们把 Memory 定义成跨会话持续存在、可更新、可审计，并且会影响未来决策的结构化历史。
现在可以再往前推一步：
Memory 的写入是经验获得长期影响力的入口，读取则是历史进入当前任务的准入过程。
因此，Memory 至少有两条完全不同的链路：
读取链：当前任务允许哪些过去进来
写入链：当前结果凭什么影响未来
只盯着向量库，会同时漏掉这两条链路里最难的部分。
日志、状态和经验，更新规则并不一样
如果要把这件事做成系统，我通常先把 Agent 运行后留下的东西分成六层。
层次
它解决什么问题
默认状态
原始证据
当时发生了什么
只追加、可追溯
当前状态
任务现在走到哪里
一个权威版本
候选经验
哪条做法可能有用
未验证、可过期
已验证记忆
哪类场景可以复用
有来源和作用域
Skill / Harness
以后默认怎样做
有版本、可回归
Policy
哪些动作允许或禁止
外部维护、单独审批
这六层看起来都和“过去”有关，更新规则却完全不同。
原始证据包括日志、Diff、测试输出、退出码、工具调用和环境信息。它们的价值在于保留现场，不能只剩一段模型总结。
当前状态描述任务已经完成什么、还差什么、哪条结论得到确认。它更像状态机或账本，需要一个权威版本，不能散落在几个 Agent 的摘要里互相打架。
候选经验允许系统先记下一个可能有用的观察，但要明确“原因未确认”“只在某个版本出现”“等待复现”。这层给不确定性留了位置。
已验证记忆才适合跨任务复用。它需要来源、时间、作用域、验证结果和失效关系。
走到
Skill
和
Harness
，系统开始改变 Agent 的默认执行方式，例如先做依赖预检、相同命令最多重试一次、修复后固定运行哪些测试。
Policy 再往外一层，负责权限、安全、预算和审批。Memory 可以引用规则，不能把一次任务里的权宜处理写成新规则。
如果这六类东西都叫 Memory，系统很快会分不清一条记录到底是日志、推断、经验，还是必须遵守的约束。
拿 Pod 被
OOMKilled
后自动重启来说，这六层会落得很具体。
容器退出原因、内存曲线、GC 日志和版本号属于原始证据；“重启后服务恢复”是当前状态；“某个版本在特定流量下可能存在内存泄漏”只能先算候选经验。等到泄漏可以复现、修复也通过回归，它才适合进入长期记忆。
再往上，“先保存退出信息和内存曲线，条件允许时采集堆转储，最多自动重启一次，仍然异常就通知值班人员”可以成为 Harness 里的处理流程。至于 Agent 有没有生产重启权限、能不能自动扩容，则属于 Policy。前者是故障处理，后者已经进入权限边界。
写入链：一次成功，只能先算观察
再看开头那次 CI 修复。
Agent 调大 timeout，测试通过。这个结果可能有几种解释：
- 超时确实是根因，修改解决了问题；
- 超时只是症状，真正的问题暂时没有触发；
- 测试本来就有抖动，这次只是碰巧通过；
- 当前用例通过了，性能或依赖问题却被掩盖了。
单次
pass
只能确认当前检查通过，无法自动排除后面三种情况。
第一次写回时，我会先把它记成观察：
Observation:
在 commit a1b2c3 上，将 timeout 从 30s 调整到 90s 后，目标测试通过。
Cause:
未确认。
Scope:
repo-x / integration-test-y / dependency-lock-z
Evidence:
原始失败日志、代码 Diff、测试命令、退出码、运行环境。
Status:
candidate
这条记录以后可以参与检索，也可以帮助排障，但它还不能直接驱动默认动作。
运维故障里很容易把这几件事写混。
kubectl rollout restart
是动作，告警消失是当时的结果，内存泄漏是不是根因，还要看 GC 日志、堆转储、流量和版本变化。若最后只剩一句“重启解决了故障”，Agent 学到的往往只是最容易执行的那个动作。
《
Loop Engineering再看：真正该设计的，是反馈契约
》里，我们把一轮任务最少要留下的内容整理成五类：
Goal：这一轮要完成什么
Evidence：看到了哪些原始事实
Action：做了哪些动作
Verdict：谁判定通过或失败
Next state：下一轮继承什么
一条候选经验要想往上走，还得补齐几个问题：
• 失败能不能在相同环境稳定复现；
• 只应用这项修改，结果是否稳定变化；
• 有没有反例或其他解释；
• 这条经验在哪些版本和任务里有效；
• 由测试、编译器、规则引擎、评审 Agent 还是人来验证；
• 什么时候重新检查，出错后回滚到哪一版。
实际做的时候，不必一开始做得很重。一张轻量的晋升单，已经能把这些信息留下来：
candidate_id:
ci-timeout-20260719-01
type:
memory
claim:
Increasing
timeout
may
mitigate
integration-test-y
failures.
scope:
repository:
repo-x
test:
integration-test-y
dependency_lock:
lock-z
evidence:
-
run_id:
run-1042
commit:
a1b2c3
command:
make
integration-test-y
exit_code:
0
counter_evidence:
[]
verifier:
kind:
test
status:
pending
expected_change:
Reduce
timeout-related
failures.
regression_risk:
Hide
dependency
or
performance
regressions.
expiry:
2026-08-19
rollback_to:
memory-version-18
pending
很重要。字段写得完整，只能说明候选可追溯，还不能说明它已经正确。
图 2：一条经验从运行结果到灰度生效的晋升流程
读取链：旧经验何时进来，哪一版进来
Memory 的读取通常被简化成一句
retrieve(query)
。
放到长任务里，至少要先过两道判断。
此刻真的需要历史吗
固定
top-k
有一个隐含假设：每一步都需要同样多、同样深、同样类型的过去。
实际运行很少这么整齐。
任务刚开始时，系统可能没有多少可用经验；已经有成熟成功计划时，几段相似日志不如一份完整计划；Agent 卡住以后，继续用原查询检索，也只会拿回相近结果；当前步骤如果只是读取一个确定文件，检索历史反而会增加噪音。
MemCon 在现有记忆后端外面增加了一层控制器，根据任务阶段、是否卡住、记忆规模和计划状态选择动作：
•
RETRIEVE
：按当前策略检索；
•
PLAN_INJECT
：注入已经提炼的成功计划；
•
RE_RETRIEVE
：发现卡住后换查询再检索；
•
CONSOLIDATE
：合并重复和零散记忆；
•
FORGET
：删除或降低无用信息的影响；
•
NO_OP
：当前步骤不使用记忆。
论文在 6 个基准、3 个 Agent 框架和 3 个模型上评估，任务成功率最高提升 15.2 个百分点，Token 消耗降低 5% 至 20%。这些数字来自指定实验，不能直接当成生产收益。
更有用的信号是，Memory 开始拥有“不读取”的能力。
在 CI 场景里，第一次看到失败日志，可以先不让旧经验定义根因；连续重复同一动作后，再用错误码、依赖版本和失败阶段重构查询；仓库和依赖已经变化，旧经验就该降权或退出默认检索。
生活里的绕路也一样。记忆里写着“上周走 B 路快了十分钟”，这句话可能完全准确，但那天 A 路正在施工。道路恢复以后，如果系统只按“更快路线”检索旧记录，不看当时的路况和有效时间，记忆越准，决定反而可能越偏。
取回来的到底是哪一版
控制了“何时取”，还要解决“取回哪一版”。
A-TMA 把一种常见故障叫作“幽灵记忆”：旧事实、当前事实和状态变化都保存在记忆库里，系统却没有标明它们在这次任务里分别扮演什么角色。
同一个 CI 问题里，记忆库可能同时有：
• 历史事实：旧依赖版本下，延长 timeout 曾让测试通过；
• 转换记录：依赖升级后，失败从启动缓慢变成协议不兼容；
• 当前事实：当前根因是依赖兼容问题，延长 timeout 已经无效。
三条记录都是真的，也都和“CI 超时”语义相关。只按相似度取回，Agent 很可能拿到最像成功方案的那一条，却忽略它已经失效。
A-TMA 没有替换原有记忆系统，而是在记忆库、检索和回答三个位置补状态语义：记录标记为
active
、
superseded
、
transition
或
unknown
；检索时按当前、历史或变化过程构造证据包；回答时明确区分不同状态。
在 LTP 基准上，Graphiti/Zep + A-TMA 的冲突准确率从 0.480 提升到 0.720。在 LoCoMo 上，temporal F1 从 0.0295 提升到 0.1705，平均 F1 从 0.0809 提升到 0.1556。
这些收益依赖宿主系统和具体指标，不能笼统概括成“准确率提升近六倍”。
从工程实现看，一条长期记忆至少需要几类状态字段：
status
valid_from / valid_to
scope
source
supersedes / superseded_by
transition_type
evidence_ref
时间戳只能说明何时发生。
supersedes
和
transition_type
才能解释一条旧经验为什么不再适用于现在。
OpenAI 的 Dreaming 也把新鲜度、连续性、相关性和随时间更新放在一起处理，并允许用户查看、修改和纠正记忆摘要。原文提到的“约 5 倍”优化，只对应免费用户版 Dreaming 的服务计算量。
记忆会影响后续决策，维护者就要能看见它、改正它，也要知道哪次运行曾经用过它。
记忆什么时候可以升级成 Skill 或 Harness
从候选经验到已验证记忆，系统只是让一段历史变得更可信。
一旦它进入 Skill 或 Harness，影响方式就变了。
Memory 通常在运行时提供参考；Skill 会把经验整理成可重复执行的流程；Harness 则会改变提示词、工具协议、控制流、重试、验证和产物规则。
简单说，记忆告诉 Agent “过去发生过什么”，Harness 开始决定“以后默认怎么做”。
这一步的晋升条件更严格。我通常会看三件事：
• 同类失败是否重复出现，而且根因相近；
• 候选规则能否在目标任务上稳定改善；
• 原本能做对的任务有没有退化，成本和权限有没有恶化。
比如，前面的 CI 经验如果反复得到验证，最后进入 Harness 的规则与其写成“超时就加到 90 秒”，更稳的修改可能是：
• 第一次超时时先收集失败阶段、资源占用和依赖变化；
• 相同参数最多重试一次；
• 第二次失败后重构诊断查询；
• 修改 timeout 前运行依赖与性能预检；
• 修复后运行目标测试和保留回归集。
它针对的是一类失败机制，没把某个偶然有效的数值写成永久答案。
架构评审里也有同样的问题。一次压测中，加缓存把接口 P99 从几百毫秒降下来，这当然是好结果。可如果缓存失效、数据一致性、热点 Key、降级和回源压力都没验证，把经验写成“慢接口优先加缓存”，迟早会在另一个系统里付学费。
如果它要进入架构 Skill，留下的更适合是一套检查顺序：先看查询计划和调用链，再确认数据新鲜度要求、失效策略和回源上限，最后跑压测、数据对账与故障演练。
Skill 保存的是解决这类问题的方法，缓存只是其中一种候选方案。
图 3：Memory、Skill / Harness 与 Policy 的影响范围和治理方式对比
到了这里，可编辑范围也分出了三层。
适合自动提案
• 任务协议和提示词片段；
• 工具说明与参数提示；
• 重试、停止和产物检查规则；
• Skill 草案和错误恢复流程；
• 低风险的上下文整理策略。
沙箱里先验证
• 工具实现；
• 中间件和控制流；
• 长期记忆的写入与合并逻辑；
• Subagent 配置；
• 预算分配和并行策略。
留在改进循环外
• 评估器和保留评估集；
• 权限策略和生产凭证；
• 模型与推理配置；
• 预算上限；
• 晋升、回滚和审计机制。
Lilian Weng 在 Harness Engineering for Self-Improvement 中提到，Self-Harness 的可编辑表面需要被限制。她介绍的 Agentic Harness Engineering 实验会把 runs 目录、tracer、verifier 和 LLM configuration 保持只读，避免候选 Harness 通过关闭验证器、替换模型或抬高预算来制造“提升”。
Polar 从另一个角度说明了 Harness 对行为的影响。它在模型 API 边界捕获原生执行轨迹，用同一个 Qwen3.5-4B 基础模型在四个 Harness 上训练：
Harness
训练前
训练后
Codex
3.8%
26.4%
Claude Code
29.8%
34.6%
Qwen Code
34.6%
35.2%
Pi
34.2%
40.4%
Codex 上的增幅最大，论文解释为基础模型原本不熟悉 Codex 的动作协议、上下文策略和补丁提交方式。训练以后，模型逐渐适应了这套运行方式。
这些数字不适合拿来比较四个产品。它们说明，Harness 承载了一部分可学习的行为协议。修改 Harness，也是在修改 Agent 以后怎样工作。
验证器决定自我改进能走多远
生成候选修改正在变得越来越容易。难的是证明它改对了。
一篇调研 1250 篇 2024 至 2026 年 arXiv 论文的综述，把当前工作分成有界自我改进和开放式递归自我改进。前者在固定目标、外部评估器和受限搜索空间里优化；后者连“什么算更好”以及怎样评估都可能一起变化。
当前绝大多数工作仍属于有界改进。放到工程里，它更接近自动提案、自动试验和受控晋升。
综述把验证信号分成四层：
1.
形式化验证器
：证明检查器、类型系统、可判定规则；
2.
执行反馈
：测试、编译器、仿真环境、真实运行结果；
3.
学习型评判器
：奖励模型、LLM-as-a-Judge、规则模型；
4.
模型内在自评
：置信度、自洽性、自我批评。
前两层的信号更硬，覆盖范围通常较窄。后两层能处理更多开放问题，也更容易受评判器能力、提示方式和指标漏洞影响。
Coding Agent 的自我改进进展更快，很大一部分原因就在这里。编译器、测试、静态检查和行为对比，可以从模型外部判错。研究方向、产品体验和架构取舍没有这么便宜的验证器，最后还得依赖业务语境、用户反馈和长期维护成本。
同样叫验证，换到不同现场，盯的东西并不一样。
•
研发修改
：代码能编译只是起点，还要看目标测试、保留回归集、Diff 和依赖变化。
•
运维动作
：告警消失也不够，还要看一段时间内的错误率、延迟、内存曲线、是否复发，以及回滚是否真的可用。
•
架构调整
：压测变快以后，还要补数据对账、故障演练、容量余量和成本变化。很多架构问题，恰恰躲在“正常流量下看起来没事”的那一段。
“执行者和验证者分开”，如果只是再叫一个 reviewer 模型，独立性仍然不够。
独立性至少包括：
•
证据独立
：读取日志、Diff、测试和环境，不只看执行 Agent 的总结；
•
上下文独立
：不继承执行者为了完成任务形成的全部假设；
•
环境独立
：在干净环境里复现，不沿用已经被修改的现场；
•
目标独立
：验证器的得分不依赖执行 Agent 是否“看起来成功”；
•
权限独立
：候选 Harness 无法修改验证器、评估集和通过阈值。
OpenAI 的 Confessions 提供了一个监测思路：模型在主答案之外再输出一份“自白”，只按诚实程度训练和评估，用来暴露走捷径、奖励黑客和违反约束的行为。
它适合发现问题，不能阻止已经发生的副作用。Agent 即使坦白“我绕过了测试”，也不能恢复被写坏的数据，权限系统仍然要在动作发生前挡住高风险操作。
这里我还没有完全想通的是，评估器自己该怎样更新。两个模型可能共享盲区，固定测试也会被任务分布变化慢慢掏空。评估器更新后由谁回归、又用什么证明新评估器更可靠，仍然是这条链路里最难自动化的一层。
两条路径，一个控制面
把这套机制收起来，系统里其实只有两条路径和一个控制面。
读取路径
当前任务与状态
↓
判断是否需要记忆
↓
选择当前 / 历史 / 变化视角
↓
构造带来源和状态的证据包
↓
进入当前工作集
写入路径
运行任务
↓
保存原始证据
↓
更新当前状态
↓
生成候选经验
↓
复现、归因和外部验证
↓
晋升为已验证记忆
↓
必要时生成 Skill / Harness 候选
↓
回归、灰度、观察和回滚
控制面
这里说的控制面不一定很重。它负责目标、评估器、评估集、权限、预算、晋升和回滚，其中既可以有人，也可以有测试、类型系统、策略引擎、独立评审 Agent 和发布平台。
这里我会单独划一条边界：Agent 接受评估时，评估器、通过阈值和生产权限留在它的可编辑范围之外。
我自己的版本是五道门：
门
通过条件
不通过时
证据门
日志、Diff、环境和版本齐全
只留事件，不生成经验
归因门
结果可复现，有对照和反例检查
保持候选状态
回归门
目标集改善，保留集无明显退化
拒绝晋升
权限门
未扩大权限和副作用范围
转人工审查
发布门
影子或灰度指标稳定，可快速回滚
回退上一版
这五道门解决不了所有错误。它们的作用是防止一次错误未经检查，就获得跨任务、跨版本的长期影响力。
同样是一次成功，为什么会停在不同层
研发：测试重试一次，绿了。
这时最多能确认“本次重试通过”。如果没有保存首轮失败日志、随机种子、依赖版本和多次运行结果，证据门都还没有走完，更谈不上把“失败就重试”写成默认规则。
运维：Pod 重启后，告警消失。
证据齐全以后，它可以成为一条候选排障经验。泄漏原因还没找到、观察窗口还没走完时，我会让它停在候选层。更稳的自愈流程是“先留现场、满足条件后重启一次、失败就升级处理”，并且给重启次数设上限。
架构：加缓存后，P99 降了。
它通过了目标性能检查，还没有自动通过一致性、回源、故障和成本几项回归。等这些结果稳定，才适合把检查流程沉淀成架构 Skill。至于缓存参数和拓扑，仍然要跟着业务场景走。
三个方案都可能是对的，差别只在于当下的证据允许它们走多远。这个边界比“成功或失败”两个状态更有用。
真要在团队里试，我会从小闭环开始
如果团队已经在做长任务 Agent、自动修复 Loop 或自生成 Skill，我不会一开始就放开 Harness 自动晋升。第一版甚至不用急着谈“自我进化”，先让 Agent 把现场记清楚、把候选说清楚，就已经很有价值。
这条路大致可以分成四段。
第一阶段，只记账
第一阶段只记录任务、工具调用、Diff、测试、退出码、状态和 Harness 版本。目标很朴素：一次失败能复盘，Agent 暂时不修改自己。
第二阶段，开始提候选
Agent 可以聚类重复失败，提出候选记忆和规则修改。人或独立验证器确认作用域、证据和风险，候选不自动生效。
第三阶段，候选自己跑回归
目标集、保留集和干净运行环境固定下来，候选自动跑回归，报告收益、退化和成本变化，再由维护者批准。
第四阶段，只开放低风险晋升
能自动晋升的规则，我会限制在输入稳定、验证明确、权限窄、失败容易撤回的范围里。高风险修改继续走人工审查。
如果一时不知道从哪里开始，CI 失败归类是个不错的小试点。输入是日志、命令、退出码、commit 和依赖版本，输出只是失败类别；验证可以用已有人工标注的历史样本和一组保留样本，分错以后也不会直接改生产系统。
文档链接修复、依赖预检、测试产物检查和重复报错聚类也有类似特点：结果容易检查，环境相对容易复现，副作用不大。它们通常比自动改生产配置更适合拿来走第一遍闭环。
我通常不会只看任务成功率。重复失败率、回归逃逸率、验证分歧率、证据完整率、规则变更频率、回滚率、执行成本和权限变化，能更早暴露“看起来成功，实际在积累风险”的情况。
安全边界同样要落到具体权限上。Anthropic 的 agentic misalignment 研究来自受控的虚构场景，他们明确表示目前没有在真实部署中观察到这类行为的证据。它更适合提醒我们关注一组条件同时出现时的风险：较高自主性、敏感信息访问、不可逆外部动作和缺少独立监督。
在权限设计上，我会把读取、写入、外发和规则修改分开。不可逆动作单独审批，候选 Harness 无法修改评估器和晋升机制，发现异常时能降级到只读或人工接管。
写在最后
回到开头那条 CI 经验。
如果第一次通过只被记成一条带 commit、依赖锁和“原因未确认”的观察，第二次失败时，Agent 仍然能参考它，却不会直接把它当成当前规则。
如果系统保留了状态变化，依赖升级后的新事实会替代旧经验。即使 Agent 进一步提出 Harness 修改，归因、回归、权限和发布几道门也会继续检查它。
研发里的重试、运维里的重启、架构里的缓存、生活里的绕路，本来都可以是好经验。问题只在于，它们有没有把当时的条件、证据和失效时间一起带回来。
这就是我理解的 Agent 记忆与可验证自我改进：
记忆负责保留可以影响未来的历史，验证负责决定这段历史能影响到哪一层。
有些信息只该留在日志里，有些可以进入当前状态，有些经过验证后成为长期经验。再往上的 Skill、Harness 和 Policy，需要更慢、更独立的变更流程。
系统不可能保证每次都学对。更现实的目标，是让每次学习都有来源、有作用域、有验证、有失效条件，也能退回上一版。
做到这一步，Agent 的“自我改进”才算有了可维护性，而不只是演示里又多跑了几轮。
参考资料
• Memory as a Controlled Process: Learned Adaptive Memory Management for LLM Agents
https://arxiv.org/abs/2607.13591
• A-TMA: Decoupling State-Aware Memory Failures in Long-Term Agent Memory
https://arxiv.org/abs/2607.01935
• Recursive Self-Improvement in AI: From Bounded Self-Refinement to Autonomous Research Loops
https://arxiv.org/abs/2607.07663
• Polar: Agentic RL on Any Harness at Scale
https://arxiv.org/abs/2605.24220
• Lilian Weng, Harness Engineering for Self-Improvement
https://lilianweng.github.io/posts/2026-07-04-harness/
• OpenAI, Dreaming: Better memory for a more helpful ChatGPT
https://openai.com/index/chatgpt-memory-dreaming/
• OpenAI, How confessions can keep language models honest
https://openai.com/index/how-confessions-can-keep-language-models-honest/
• Anthropic, Agentic misalignment: How LLMs could be insider threats
https://www.anthropic.com/research/agentic-misalignment
标签：#主题/AI-Agent #主题/记忆系统 #主题/Harness #主题/验证 #场景/公众号长文