Meta刚以20亿美元收购了Manus。一位开发者深入研究了其核心工作原理，并将关键模式开源分享。
AI Agent面临一个普遍困境：经过大量工具调用后，它们会逐渐迷失目标。上下文膨胀、错误被淹没、任务偏离轨道。
Manus的解决方案出奇简单——仅用三个Markdown文件：
- task_plan.md：用复选框追踪进度
- notes.md：存储研究内容，避免塞满上下文
- deliverable.md：最终交付物
核心机制是：Agent在每次决策前都会重新读取计划文件，确保目标始终停留在注意力窗口内。
这个发现引发了社区热烈讨论，也暴露出一些关键洞见：
关于"这不是什么新东西"的质疑，确实如此。Claude Code本身就会自动创建plan.md文件，Spec-kit、APM等开源工具早已实现类似工作流。但这恰恰验证了这个模式的有效性——当多个独立开发者不约而同地收敛到同一解决方案时，说明它确实解决了真实问题。
关于"写入notes.md不也是在填充上下文吗"的技术追问，这是个精准的观察。写入操作确实会产生token消耗。但关键不在于减少token数量，而在于注意力操控。LLM存在"大海捞针"问题——随着上下文增长，它们会逐渐遗忘早期目标。通过在每次重大决策前重新读取计划文件，目标被强制拉回注意力窗口。
社区提出了更进阶的方案：使用子Agent处理上下文密集型任务。主Agent保持轻量，只负责追踪进度和协调；子Agent在独立上下文中完成繁重工作后汇报结果。这样既保持了主Agent上下文的清洁，又能处理复杂任务。
一位开发者分享了他的实战经验：将Claude视为员工，一次只分配一个任务，每完成一步就提交git，全程人工审核。这是8小时工作日的节奏，不是"设置后就忘"的自动化。
关于工作流设计的最佳实践：保持CLAUDE.md极度精简，只描述核心行为预期；将数据库、API等专项知识拆分到独立文件，仅在相关任务时加载；维护一个愿望清单，让未来功能不干扰当前工作。
有人一针见血地指出：20亿美元买的不是三个Markdown文件，而是一家6个月创造1亿美元收入的公司，以及其虚拟机能力、浏览器自动化和完整Agent平台。这个模式只是其中一块拼图。
这场讨论揭示了一个更深层的趋势：上下文工程正在成为一门独立学科。我们正在见证"Agent工程师"这个新角色的诞生——他们是软件工程师，但具备云服务、API和Agent能力的综合知识。
最实用的一句话总结来自社区：Claude是我的员工，我给它分配任务、检查每个任务、控制每个步骤。不要试图让Claude一次完成所有事情，那是不可能的。
reddit | 原始技能仓库 |Spec-kit |多Agent管理框架APM | Manus上下文工程博客
