我是 Abin，这里记录我对技术和产品的思考。
Harness²：Agent 开始自己调 Harness 了
Harness² 让 Agent 根据执行轨迹修改运行配置，再重跑任务、保存经验。以渠道季度报表为例，可以看到 skill 和 guardrail 怎样改变执行行为，以及怎样从成本、归因和泛化三个角度评价自动调优。
Mem0 怎样管理长期记忆：事实提取、冲突整理与跨任务召回
Mem0 把对话提取成可搜索的事实，外层 Agent 决定存取时机与上下文注入。沿着一次 Jest 到 Vitest 的约定变更，拆解 OSS V3 的单次提取、持久化、混合排序，以及 Platform Dream 的冲突维护边界。
Agent 的记忆插件怎样工作：主动保存、后台提炼与按需召回
一条项目约定怎样跨会话生效？沿着 Pi 记忆插件的工具、生命周期钩子和请求注入，比较主模型主动保存、会话后提炼与后台整理三条路径，再看 Claude-mem 的观察记录和 QMD 的检索分工。
Codex 怎样形成跨会话记忆：从会话提取到按需召回
Codex 把历史会话加工成逐条摘要，再整理成新会话的记忆入口。沿着一条用户纠正，追踪两阶段写入、V1/V2 文件结构、冲突整理与按需召回，理解跨会话记忆怎样影响后续工作。
Agent 怎样跨窗口继续工作：Notes、History 与任务恢复
另一种换窗策略：Agent 先把任务状态写进 Notes，再打开新窗口，按需从 History 读回细节。以支付改造为例，拆解状态提炼、换窗 guard、恢复和程序接管怎样配合。
Agent 的上下文满了以后：本地压缩与远程压缩
支付代码改到一半，上下文快满了。用同一个任务看清两条路径：Pi 生成文本摘要，再接上近期消息；OpenAI Responses 返回压缩状态，供后续请求继续使用。
对象存储灰度的哈希路由
线上 R2 网络问题暴露了单对象存储风险。改造方案引入阿里云 OSS，通过 storage.Client 抽象、FNV-1a id 哈希路由和 threshold 控制新上传流量，支持灰度与切回。
谁的缰绳更好：Harness 生态竞争全景
Harness 生态已经远不止几个 coding agent 在打擂台了。终端、IDE、个人助理、通用平台——不同形态的 harness 正在沿着多个维度同时竞争。这篇试着画一张竞争地图。
Harness Engineering：Agent 的问题，开始变成软件工程问题了
当数据和权限问题暂时不再构成障碍，Agent 为什么还是经常无法稳定完成工作？很多时候，短期瓶颈不在模型本身，而在你有没有给它搭好工作环境：状态如何延续、工具如何调用、环境如何约束、结果如何验证。
围墙里的 Agent：谁会先推倒第一块砖
数据拿不到，有人选择在自己的围墙里做闭环（阿里），有人选择翻墙（豆包手机），有人选择假装墙不存在（大部分 Agent 产品）。谁会先推倒第一块砖？