职贝云数AI新零售门户

标题: Manus 创始人揭秘 Agent 的关键是上下文工程 [打印本页]

作者: ebE3N 时间: 昨天 15:29
标题: Manus 创始人揭秘 Agent 的关键是上下文工程
一、为什么选择上下文工程
2023 年终，摆在 Manus 团队面前有两条不同的技术道路：一条是“炼模型”，即从零末尾训练或微调一个端到端的 Agent 专属模型；另一条是构建“上下文工程”，即完全不动模型参数，只靠构建上下文工程完成Agent行为。
表面上看，炼模型似乎更“根正苗红”，但它意味着每次需求变动都要重新搜集数据、重新训练、重新评价，周期动辄数周甚至数月，对仍在寻觅产品市场契合度的创业公司来说，这种慢反馈几乎等于判死刑。更残酷的是，大模型本身的迭代速度远超小团队——明天炼好的公用模型，明天就能够被新一代通用模型碾压。
于是团队把成绩倒过来想：既然 GPT 等前沿模型曾经具有弱小的上下文学习才能，为什么不把“模型才能”当作恒定且持续下跌的潮水，而把精神花在造一艘能随潮而起、随潮而变的船？
上下文工程正是这艘船，它让产品迭代周期从“数周”大大紧缩，让团队专注于业务逻辑而非 GPU 预算，也让 Manus 得以与底层模型解耦，随时享用新一代大模型带来的功能红利，而不必被底层模型锁死。
二、Manus 上下文工程最佳实际
第一条法则关于KV缓存。为了让Agent跑得又快又便宜，他们把全部心思放在KV缓存命中率上。做法其实很简单：提示词的前缀最好原封不动，别在扫尾加准确到秒的工夫戳；每次给模型的上下文只追加新内容，不会修正历史记录；假如系统不支持自动缓存，就手动插入断点标记。靠着这三个缓存策略，把命中率从23%提升到87%，推理成本大幅降低，大幅提升呼应速度。
第二条法则关于工具管理。Agent的才能越强，可调用的工具就越多，但工具越多，模型越容易选错。他们试过动态增删工具，却发现每次改动都会把KV缓存全部清零。于是换了个思绪：一切工具一直留在上下文里，只是在解码时用形态机把不合时宜的选项“屏蔽”掉，而不是真的删除。这样一来，缓存不会失效，模型也能选到正确的工具，既保住了功能，又降低了出错率。
第三条法则把文件系统当成有限记忆。再大的模型上下文窗口也装不下网页、PDF这类大块头，他们把文件系统当作外部记忆：上下文里只保留文件途径，详细内容让Agent在需求时本人读。这样紧缩上下文长度的同时，信息却永远不会丢失，而且文件内容可以随时更新。
第四条法则用“复述”来防止走神。复杂义务动辄几十步，模型容易遗忘最后目的。他们让Agent在运转过程中不断重写一份todo list，把义务目的用自然言语重新写到上下文末尾，相当于把全局计划每次都放在上下文中，让每一步拆解的子义务目的分歧，义务完成率也随之得到提高。
第五条法则主张把错误留在现场。传统做法里，一出错就赶紧清算痕迹、重试操作，但这样做反而把学习机会也一同擦掉。他们反其道而行，保留每一次报错、每一次堆栈跟踪，让模型在上下文中亲眼看到“哪里出现了错误”。结果，Agent在后续步骤里会自动绕开相反的坑，义务成功率也得到提升，阐明错误痕迹本身就是最好的教师。
第六条法则提示别被少样本提示困住。为了让模型表现更好，人们常给它看一堆相似例子，但例子太划一，Agent容易堕入机械反复。我们在每一步故意加入宏大变化：同一段信息用不同的JSON格式、不同的措辞、不同的顺序呈现。加入这种随机性，既保留了对大模型都指点价值，又打破了途径依赖，让Agent保持灵敏，不至于一条路走到黑。

🈶 相关引荐

大模型基础实际，Google 在跟本人较劲

ChatGPT 发布端到端 Agent

百度上线简单搜索

黄仁勋点赞11家中国公司

Kimi 开源 K2

欢迎光临职贝云数AI新零售门户 (https://www.taojin168.com/cloud/)