Peak
定义或身份
Peak，中文名季逸超，是 Manus 的联合创始人兼首席科学家。
在所引文章中，他既不是单纯的对外发言人，也不是只负责局部算法实现的研究者，而是 Manus 技术路线的重要判断者。文章明确写到，在团队讨论某个功能如何实现时，他会习惯性先思考：这个功能能否在产品里形成网络效应。
他也是 Manus 关于 Agent 上下文工程经验的主要分享者。文中多项原则——包括围绕缓存设计上下文、用掩码而非移除来限制动作、把文件系统当作长期记忆、通过复述维持目标注意力、保留失败痕迹做错误恢复——均由他以第一人称总结。
角色职责
1. 负责技术路线判断
Manus 项目初期，团队面临一个关键选择：
- 是利用开源基础模型训练一个端到端 Agent；
- 还是依托前沿模型的上下文学习能力，在其上构建 Agent。
Peak 给出的判断是押注后者，也就是押注 Agent上下文工程实践 摘要|上下文工程。
这不是抽象口号，而是建立在他过往创业和 NLP 研发经验上的判断。他回顾说，在 BERT 刚问世后的时代，模型迁移到新任务通常必须经历微调和评估，每次迭代往往耗时数周。对于仍在验证 PMF 的产品，这样的反馈周期几乎是致命的。
2. 决定 Manus 与底层模型保持正交
Peak 用一句很有代表性的比喻说明自己的路线观：
如果模型进步是上涨的潮水，我们希望 Manus 是船，而不是钉在海床上的柱子。
这句话体现了他的核心技术立场：Manus 不应把价值过度绑定在某个特定底模或一套难以迁移的训练资产上，而应把重点放在能跨模型迁移的上下文塑造、执行机制和工程闭环上。
因此，他强调 Manus 与底层模型进步应当保持“正交”：模型更强时，Manus 可以直接受益；模型替换时，系统方法也不必整体推倒重来。
3. 分享一线 Agent 实战经验
Peak 在文中不是以理论研究综述的方式发言，而是以连续试错后的工程复盘者身份发言。他明确说，上下文工程“远非一帆风顺”，是一门实验科学；Manus 已经四次重构智能体框架，每次都是因为找到了更好的上下文塑造方式。
他们甚至把这种手动做架构搜索、提示微调和经验猜测的过程戏称为“随机梯度下降”（Stochastic Graduate Descent，原文如此表述）。这个说法也反映出 Peak 的方法论：先在真实任务和真实用户规模里反复试验，再把有效模式沉淀为工程原则。
关键信息
押注上下文工程，而非端到端自训练 Agent
Peak 做出这一路线判断，直接受到其上一家创业公司的经历影响。他曾从零训练模型，用于开放信息抽取和语义搜索；但随后 GPT-3 与 Flan-T5 出现，使那些自研模型很快失去意义。
这段经历让他得到一个明确教训：如果产品能力过度依赖自训练模型资产，底层范式跃迁时，之前的投入可能会迅速贬值。相反，基于前沿模型的上下文学习能力构建 Agent，可以把迭代速度从“数周”压缩到“数小时”。
对 Peak 来说，这不仅是效率选择，也是生存策略和架构策略。
强调能力间的复合效应与网络效应
Peak 对功能设计的一个重要判断标准，是新能力能否与已有能力产生耦合与放大，而不是只看单点功能是否成立。
文中给出的具体例子是：加入图像读取能力后，Manus 不只是多了一个“看图”能力，还出现了新的复合效果——它能够自行调试生成的数据可视化代码，甚至还能“神奇地修复”其他模块的问题。
这说明 Peak 关注的是通用 Agent 中能力之间的组合收益，而不是孤立能力堆叠。
把上下文工程视为 Agent 的核心工程学
Peak 认为，即使模型会继续变得更强、更快、更便宜，Agent 的可用性仍取决于如何塑造上下文，因为仅靠底模原生能力并不能替代记忆、环境和反馈机制。
在这个意义上，他分享的不是单个 prompt 技巧，而是一整套面向生产系统的上下文工程观。
Peak 重点分享的 Manus 实战原则
1. 围绕 KV 缓存设计
Peak 明确表示：如果只能选一个指标，生产级 Agent 最重要的单一指标就是 KV 缓存命中率，因为它直接影响延迟和成本。
他解释了原因：Agent 每一步都会把动作和观察追加到上下文里，而输出通常只是较短的结构化函数调用，因此其输入/输出 token 比例远高于普通聊天。Manus 的平均输入与输出 token 比例约为 100:1。
在这种场景下，前缀缓存价值极高。Peak 以 Claude Sonnet 为例指出：缓存输入 token 的价格约为 0.30 美元/百万 token，未缓存输入 token 约为 3 美元/百万 token，价差达到 10 倍。
他给出的实践要点包括：
- 保持提示前缀稳定；
- 让上下文始终追加式增长，不回写历史动作和观察；
- 保证序列化是确定性的，尤其避免 JSON 键顺序漂移；
- 在需要手动设置缓存断点的框架中，至少确保断点覆盖系统提示结尾；
- 若自行托管模型并使用 vLLM 等框架，要确认启用前缀/提示缓存，并通过会话 ID 等方式保证请求在分布式节点间的一致路由。
这些内容可对应到 KV缓存友好型上下文。
2. 用掩码约束动作，而不是动态移除工具
Peak 指出，随着 Agent 能力扩展，工具数量会迅速膨胀，尤其在允许用户自定义工具时，行动空间很容易失控。工具太多会让模型更容易选错动作或走低效路径，结果反而让“更强”的 Agent 变笨。
Manus 曾尝试按需动态加载工具，但 Peak 总结出的规则是：除非绝对必要，否则不要在迭代中动态增删工具。
他给出两个具体原因：
- 工具定义通常位于上下文前部，任何变化都会破坏后续全部动作与观察的 KV-cache；
- 如果历史动作仍引用当前上下文里已消失的工具，模型会混乱，甚至出现模式违规或幻觉动作。
因此 Manus 采用的是“上下文感知状态机 + 解码阶段 logits 掩码”的方式：不真正删除工具，而是根据当前状态阻止或强制模型选择某些动作。
Peak 还分享了可操作细节：
- 常见函数调用模式可以分为 Auto、Required、Specified 三类；
- 通过响应预填充，可以把模型限制到“必须调用函数”或“必须从特定函数子集里调用”；
- 为了让子集约束更容易实现，Manus 给工具名设计了统一前缀，例如浏览器工具统一以
browser_开头，命令行工具统一以shell_开头。
这使 Manus 能不改工具定义就限制动作选择，保持 Agent 循环稳定。