以前使用Codex做长任务，常见问题是：Agent不知道你刚才在别的地方做过什么。

真实开发流程往往是：

Slack讨论需求 → 浏览器查文档 → VS Code改代码 → GitHub看PR → 再回Codex继续。

Computer History出现以后，这个问题开始变化。它可以把允许的App和网站中的近期活动整理成Timeline和Memory，让ChatGPT和Codex后续找回之前做过的工作。

但新的工程问题也随之出现：

Agent知道得越来越多以后，怎么判断哪些信息应该相信？

过去Context Engineering主要解决“信息不够”，以后还要解决“信息太多、来源不同、时效不同、权威级别不同”。

一、Computer History真正改变的是Context来源

过去Codex的上下文主要来自Prompt、Repository、AGENTS.md、当前Thread和Tools；加入Computer History以后，又会扩展到Slack、浏览器、Docs、IDE、GitHub和Memory。

问题是，这些信息并不具有相同权威级别。

例如AGENTS.md写：

“数据库Migration必须先跑Integration Test。”

这是正式规则。

Slack里有人说：

“要不要先不跑Integration Test，快速试一下？”

这可能只是讨论。

如果Agent把两者当成同等Instruction，Context越多，反而越容易做错。

所以Computer History之后，第一个要建立的不是More Context，而是：

Context Authority。

二、History应该是Recall，不应该直接升级成Rule

可以简单分成三层：

• Authoritative Context：Repository、AGENTS.md、Approved Docs、Tests、Current PR，决定正式规则和当前事实。

• Current Task Context：Thread、Goal、Diff、Checkpoint，决定Agent正在做什么。

• Historical Context：Computer History、Memory、Old Chats、Slack、Visited Docs，主要回答“以前发生过什么”。

所以更稳的链路应该是：

History → 找到线索 → 回到Current State验证 → 再执行

而不是：

History → 直接执行

例如昨天Slack里大量讨论“把缓存改成Redis”，但最后PR并没有采用。

如果Agent把高频出现理解成最终决定，就会把Discussion错误升级成Decision。

所以必须明确：

Discussion ≠ Decision
Proposal ≠ Approved Design
Memory ≠ Current Truth

三、真正危险的是Stale Context

历史信息很多时候不是错误，而是已经过期。

昨天记录的可能还是API v1，今天团队已经合并API v2 Migration。

这时你让Codex“接着昨天继续”，如果Agent直接沿用旧History，就可能继续围绕API v1分析，但Repository已经变成API v2。

这就是Context Drift。

所以Historical Context进入执行前，至少要检查：旧文件、旧API、旧Branch和旧Decision现在是否仍然有效。

这和Thread Handoff、PR Recovery其实是同一个底层问题：

Old Context ≠ Current State。

Agent拥有长期记忆以后，“记得太久”同样会出问题。所以成熟的Agent不是只会Remember，还必须会Revalidate。

四、跨应用Context会带来两类污染

第一类是Cross-project Context Pollution。

很多开发者同时维护多个项目。上午你在Project A里研究JWT，下午打开Project B，而Project B也有auth.ts、login、token。

如果History把上午的大量Context带入下午任务，就可能出现：

Context from A → influences B

所以开始长任务前，先明确Repository、Branch、Goal和Environment，再让History补充过去发生过什么。

第二类是External Context风险。

当Context来自网页、Slack、Docs等外部内容后，外部信息可能经过History重新进入Agent上下文。

如果某个页面存在恶意或误导性Instruction，而Agent把它当成命令，就可能把Data错误理解成Command。

因此要明确：

External Content = Data
External Content ≠ Instruction

尤其涉及Shell、Git、MCP、文件写入或外部API时，更应该重新确认Intent和Permission。

五、Computer History不应该代替AGENTS.md和Skills

如果History发现你每天都重复：

看Issue → 找代码 → 修改 → 跑测试 → 写PR Summary

长期最好的结果，不应该是“让History越来越长，每次靠AI回忆”。

更合理的是：

Repeated History → Pattern Detected → Human Review → Skill / Automation

因为Memory更像“以前通常怎么做”，Skill则定义“以后这类任务应该怎么做”。前者是Observed Behavior，后者是Explicit Workflow。

同样，一条经过长期验证的规则，也不应该永远只存在于Slack、旧Chat或Memory里，而应该逐渐提升到AGENTS.md、Documentation、Tests或Skill。

也就是：

Temporary Context → Verified Knowledge → Persistent Rule

它更长期的价值，是把隐式习惯逐渐变成正式工程能力。

六、给Context建立明确的优先级

如果Computer History进入日常开发，我建议建立四级优先级。

Level 1：Current State：Repository、Diff、Tests、PR，当前事实。
Level 2：Explicit Rules：AGENTS.md、Approved Docs、Team Policy，正式规则。
Level 3：Current Task Context：Thread、Goal、Checkpoint，当前任务认知。
Level 4：Historical Context：Computer History、Memory、Old Chats、Slack、Browser Activity，辅助线索。

最终执行逻辑应该是：

History → Locate Context → Current State Verification → Decision

而不是：

History → Decision

这套Context Precedence真正解决的是：

发生冲突时应该相信谁。

七、真正需要建立的是Context Governance闭环

过去Context Engineering更多关注Prompt、Thread和AGENTS.md；Computer History之后，还要判断什么值得记住、什么已经过期、什么属于别的项目，以及什么应该升级成正式规则。

所以Context Engineering会进一步走向：

Context Governance。

可以压缩成5步：

1. Recover：从History找到相关工作、文档和讨论。
2. Classify：判断它属于Discussion、Proposal、Decision、Rule还是Evidence。
3. Verify：回到Repository、PR、Tests和正式Docs确认是否仍然成立。
4. Execute：验证通过后再进入代码修改、Tool Call、Shell或Git操作。
5. Promote / Expire：长期有效的信息提升到AGENTS.md、Skill或正式文档，过期内容则退出后续Context。

完整链路就是：

History → Recover → Classify → Verify → Execute → Promote / Expire

而不是：

Remember → Trust

最后

Computer History解决的是一个真实问题：人不想每次重新解释自己刚才在Slack、浏览器、IDE和GitHub里做过什么。但Context越丰富，越需要管理来源、时效、边界和权威级别。

更合理的结构应该是：

Computer History = Recall Layer
Memory = Helpful Context Layer
AGENTS.md / Approved Docs = Rule Layer
Repository / Tests / PR = Current Truth

最终：

More Context + Clear Authority + Freshness Check + Verification = Reliable Agent

所以Computer History真正值得关注的，不只是：

“Codex终于能记住更多东西了。”

而是：

当Agent开始拥有跨应用、跨时间甚至跨项目的长期Context以后，我们需要从“怎么给Agent更多上下文”，进一步走向“怎么治理这些上下文”。

这可能才是Computer History之后，Context Engineering真正进入的下一阶段。

---

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道。