"Manus 之前分享过他们做 Agent时很多的Context Engineering 实践。
一个典型的 Manus 任务平均大概会调用 50 次工具，这么长的执行链路非常容易出现 Context 过长和失焦的问题，所以他们把文件系统本身当成了外部 Context：网页内容、文档等可以从模型 Context 里拿掉，只保留 URL、文件路径，后面需要的时候再重新读取，尽量让 Context 的压缩是可恢复的。
另外一个大家用 Manus 时应该经常见到的就是 todo.md，Manus 会在复杂任务过程中不断更新 Todo，本质上是不断把全局目标重新“复述”到 Context 的最新位置，避免任务跑久后模型忘了自己到底在干什么。
Manus 甚至认为生产环境 Agent 最重要的指标之一是 KV-Cache Hit Rate，因为 Agent 和 Chatbot 最大的不同，就是会在几十次 Tool Call 中不断增长 Context。
Manus 另外一个我觉得很重要的创新，是直接给 Agent 一台完整的计算机。
Manus Sandbox 本身就是每个任务独立的一台云端 VM，里面有网络、文件系统、浏览器、各种软件工具，Agent 甚至可以自己写代码来解决问题，而不再只是依赖预先给它定义好的几个 Tool。
后来又进一步做成了可以 24*7 持续运行、文件、安装的软件和进程都可以跨 Session 保存的 Cloud Computer。
这个抽象其实非常重要，它把 Agent 从“模型 + 一堆 API”，变成了“模型 + 一台真正可以持续干活的电脑”。
Anthropic 在这方面做的研究就更多了。
去年那篇《Effective harnesses for long-running agents》非常典型，他们发现即使 Claude 已经有 Compaction，让模型直接去完成一个跨多个 Context Window 的复杂开发任务，还是会碰到两个问题：
一个是一次想做太多，Context 用完时留下一堆半成品；
另一个是做了一部分以后看到已经有不少成果，就认为整个任务已经完成了。
为了解决这些问题，他们专门设计了 Initializer Agent + Coding Agent：
第一个 Agent 先生成完整 Feature List、init.sh、claude-progress.txt 和 Git 初始状态；
之后每一个新的 Coding Agent 都先读 Progress、Git History 和 Feature List，只选择一个还没完成的 Feature 往前推进，做完后再把状态留给下一棒，而且 Feature 只有实际测试通过以后才能标记为完成。
说白了，很像给一群不断失忆、轮班工作的程序员建立了一整套交接班制度。
到今年 Anthropic 又把这套东西进一步做成了 Planner + Generator + Evaluator 三 Agent 的 Harness，把复杂任务拆解、执行和验收分开，Generator 和 Evaluator 甚至会先协商这一轮到底什么叫“完成”，Evaluator 再用 Playwright 实际操作应用做 QA。
一个实验里，单 Agent 跑了 20 分钟、花了 9 美元，但核心功能并没有真正工作；完整 Harness 跑了 6 个小时、花了大约 200 美元，最后产出的应用完整度明显更高。“
长期来看，我非常相信通用大模型会不断提升对 Agent开发的友好性（从 deepseek v3.2 上可以明显看到这个方向），尤其是对 long running task 的友好支持，那就意味着大模型一定会更好的解决现在的大模型的上下文大小、失焦这两个主要问题。
但短期确实没办法，做 AI Agent的工程落地上，还是得特别注意处理这两块，目前阶段也会是竞争的壁垒。"
* DeepSeek 最近开源的 Harness 就非常典型。
现在里面已经有持久化 Session、Goal、Plan、自动 Compaction、Tool Result Pruner、Subagent、Sandbox、Background Jobs 等一整套能力。
比如 Context 接近上限时会自动把早期历史压缩成 Summary，原始信息仍然保存在 Session Log 中；
过大的 Tool Result 可以先裁剪；
Goal 本身则成为可以持续驱动后续执行的状态。
很多以前需要 Agent 公司自己解决的问题，已经直接进入 Harness。
* Anthropic 也在把自己过去做 Harness 的经验产品化。
一方面，模型本身的 long-running 能力不断提高，例如以前 Sonnet 4.5 需要 Context Reset 才能解决的 “context anxiety”，到了 Opus 4.5 已经不再需要；到了 Opus 4.6，连以前为了保持任务连贯专门设计的 Sprint 拆分都开始可以去掉。
另一方面 Anthropic 又推出 Managed Agents，把 Session、Harness、Sandbox 直接抽象成平台能力；同时 Tool Search、Programmatic Tool Calling 又把大量 Tool Definition 和 Tool Result 塞进 Context 的问题往底层解决。
* OpenAI 现在则更加直接。
9 月 10 日刚发布的 Agents API，官方开门见山就说，一个好用的 long-running Agent 需要 Harness 来管理 Context、高效使用 Tools、协调 Subagents，同时还需要可以让 Agent 可靠运行数天、操作文件、运行代码和保存中间结果的基础设施，所以 OpenAI 干脆把 Codex 后面的整套 Harness 和 Infrastructure 都作为 API 提供出来。
自动 Context Compaction、Tool Search、Programmatic Tool Calling、Multi-Agent、Hosted Sandbox 等能力都已经直接包含在里面，而且 OpenAI 自己维护 Harness，跟着模型能力一起升级。
* Google 走的更像是 Agent Runtime / 基础设施这条路。
现在的 Agent Runtime 已经直接支持持续数天的 Workflow，同时有 Agent Sessions、Memory Bank、Agent Sandbox 和 Agent-to-Agent Orchestration；今年又推出 Agent Executor，通过 Event Log + Snapshot 解决长时间任务中 Agent、Harness、Tool、Sandbox 任何一个部分挂掉后怎么恢复执行的问题。
当时为了避免 Agent 做到一半忘记进度、或者过早宣布完成，他们设计了 Initializer Agent、Feature List、Progress File，让新的 Agent Session 知道前面干了什么、接下来应该干什么。
但到了今年，他们又发现了另一个很有意思的现象，以前 Sonnet 4.5 在 Context 快耗尽的时候，会开始急着收尾任务，也就是 “context anxiety”，所以当时 Harness 里专门加了 Context Reset，结果换到 Opus 4.5 后，这个问题本身已经没了，以前用来解决模型缺陷的 Context Reset 反而变成了 dead weight。
Anthropic 自己总结得很直接： Harness 会编码很多“模型目前自己还做不到什么”的假设，但这些假设会随着模型进步而过时。"