思考记录来自联合创始人兼首席科学家季逸超的一个三小时访谈。 播客链接：https://www.xiaoyuzhoufm.com/episode/695331cb2db086f897b50ea9
有技术观点，干货特别多，对于业务 AI 工作流未来技术方向有一些指南。从发布不到一年时间估值 50 亿美金被收购也是深感 AI 时代的机遇、学习下先进的认知。
核心逻辑在于：不要试图把所有赌注押在训练模型上（微调），而是通过极致的”上下文工程”（Context Engineering）来榨干现有大模型的潜力。
功能模块对比
| 功能模块 | 传统/直觉做法 | Manus/反共识做法 |
|---|---|---|
| Prompt | 极简，依赖模型智商 | 极繁，包含大量规范、状态回显、Few-shot 示例 |
| 工具加载 | 按需检索 (RAG)，动态插入 | 全量静态加载，利用 KV Cache 加速 |
| 纠错 | 隐藏错误，后台静默重试 | 暴露错误，将 Traceback 作为 Context 输入 |
| 长文本 | 全文丢入 Context Window | 外挂文件系统，让模型使用 read/search 工具 |
| 记忆 | 依赖模型的隐式上下文 | 显式维护 todo.md 或 memory.json |
| 模型选择 | 尝试微调小模型以省钱 | 只用最强模型，靠 Context 优化 ROI |
1. 反对盲目自研模型，主张”上下文工程”至上
共识： 为了更好的效果，应该去微调（Fine-tune）或自研垂直模型。
反共识： 不要训练模型，而是做上下文工程。
季逸超认为，上一代NLP创业失败的教训就是试图与OpenAI比拼模型能力。在Agent时代，核心壁垒在于如何构建Context（上下文），让通用的聪明模型能正确干活，而不是自己去造一个懂垂直领域的”偏科”模型。
业务开发怎么做？ 微调（Fine-tune）或自研垂直模型业务团队也无资源深入，重点做好上下文、文档搭建工作。
不要预设一些角色，这些只是人类社会局限下的yy，比如预设一些设计师、律师等职业。反而也会限制大模型能力。所以不要再 prompt 中限制”你是谁”——“我是前端开发专家”、“我是设计专家”之类的。
2. 反对动态工具加载（如MCP），坚持静态工具列表
共识： Agent应该使用类似 MCP（Model Context Protocol）或RAG的机制，根据任务动态加载工具，以节省Token。
反共识： 动态加载工具会让Agent变蠢。
原因：
- 动态增减工具会导致模型的 KV Cache（键值缓存）失效，极大地增加推理成本和延迟
- 模型在面对不断变化的工具列表时，更容易出现幻觉或选错工具
Manus的做法： 保持工具列表静态不变（Full Set），利用KV Cache复用计算。如果某个工具在当前场景不可用，他们使用掩码（Masking）技术在概率层面上屏蔽它，而不是从Context中删掉它。
业务开发怎么做？
保持 System Prompt 前缀一致：不要根据用户的每一句话去后台检索”可能用到的工具”然后插入 Prompt。相反，在 System Prompt 中硬编码一个全量工具集（Full Toolset）。
做法：即使你有 50 个工具，只要 Context Window 允许，就全部定义在 Prompt 开头。
收益：大模型推理引擎（如 vLLM）会自动缓存这部分固定前缀（KV Cache）。当用户发新消息时，模型不需要重新计算工具定义的 Token，首字延迟（TTFT）会大幅降低。
用”软屏蔽”代替”硬删除”：如果某些工具在当前场景下确实不可用（例如用户未登录），不要从 Prompt 中删掉它（这会改变前缀，破坏缓存）。
做法：在工具描述中动态注入状态。例如：
Tool: get_user_balance (Status: Disabled - User not logged in. Do not call.)
进阶：在推理侧使用 Logit Bias（掩码）将该工具对应的 Token 概率降为 0，物理上禁止模型生成该工具的调用代码。
3. 反对隐藏错误，主张”让模型看到失败”
共识： Agent如果执行出错，应该在后台重试，不要把错误信息暴露给模型，以免干扰它。
反共识： 保留错误信息是最好的纠错机制。
如果把错误擦除重来，模型可能会重蹈覆辙。Manus会把执行失败的报错信息留在Context里，作为”负面样本”（Negative Prompting），让模型知道”刚才那条路走不通”，从而自我修正。
业务开发怎么做？
构建”执行-反馈”闭环：当 Agent 调用的工具抛出 Exception 时，不要在 try-catch 后只返回一个”出错了，请重试”的通用提示。
做法：捕获完整的 Stack Trace 或错误信息，将其作为 Tool Output 原样塞回给模型。
Prompt 暗示：“工具执行失败，错误信息如下：[Error Details]。请分析错误原因，修改你的参数或尝试其他方法。“
4. 反对依赖超长上下文，主张”文件系统即无限内存”
共识： Context Window（上下文窗口）越大越好，把所有资料都塞进去。
反共识： 不要滥用长上下文。
长上下文会显著降低推理速度（Time to First Token）并增加成本。模型厂商的大 context 并不能解决真问题，并且快溢出的时候会限制降智，压缩整理能力还欠缺。
Manus的做法： 把文件系统当作Agent的”外挂硬盘”。Agent不应该把所有读过的书都背下来（塞入Context），而应该学会”去图书馆查书”（读取文件系统）。只在Context里保留当前任务最关键的信息。
业务开发怎么做？
给 Agent 配备虚拟文件系统（VFS）：不要把所有业务资料（PDF、文档）一次性解析成文本喂给模型。
做法：为每个 Session 创建一个临时沙箱目录。给模型提供 read_file(path, line_range)、grep_file(keyword)、write_file(content) 等工具。
只加载”当前关注点”：当模型需要处理长文档时，强迫它先看目录，再按需读取特定章节。
收益：大幅节省 Token 成本，且避免了长 Context 带来的注意力分散问题。
5. 反对隐式记忆，主张显式”背诵”（Recitation）
共识： 模型能记住Context开头的内容。
反共识： 模型有”中间迷失”（Lost in the Middle）现象。
随着任务进行，Context越来越长，模型会忘记最开始的目标。
Manus的做法： 强制Agent维护一个todo.md清单，并且在每一轮对话的末尾显式地重写当前的进度和下一步计划。这相当于让模型不断地”默念”目标，防止跑偏。
业务开发怎么做？
设计”思考-行动”循环结构：不要只把对话历史扔给模型。强制模型在每次输出 Action 之前，先输出一段 Structured Reasoning（结构化推理）。
Prompt 模板示例：
你是一个智能助手。在采取任何行动之前，必须先按以下格式输出：
1. Current Status: (当前任务做到哪一步了？)
2. Thought Process: (分析当前情况和阻碍)
3. Plan Update: (是否需要修改 Todo List？)
4. Next Action: (具体的工具调用)
维护一个持久化的 todo.md：在代码层面维护一个变量 current_plan。
做法：每次模型执行完一步，要求它更新这个 Plan，并在下一轮对话的 System Prompt 中，把最新的 Plan 显式地展示给它看。
代码逻辑：System Prompt = Base_Prompt + Static_Tools + Current_Todo_List
6. 商业视角：AI不是互联网，而是制造业
共识： AI软件也是SaaS，享受互联网的零边际成本红利。
反共识： AI更像传统的制造业。
互联网软件多一个用户几乎不增加成本，但AI Agent多一个用户，Token消耗是线性的，算力成本是刚性的。
因此，AI创业不能像移动互联网那样先烧钱换规模，必须从第一天起就精细化算账，关注 Unit Economics（单体经济模型）。
所以他们是按量付费，核心高端用户不care价格，care效果、生产力。未来 Token 会像制造业能源降低费用，但是初次用户心智是无价的。
业务开发怎么做？
激进的”早停”策略（Early Stopping）：如果 Agent 陷入了死循环（例如反复报错、反复修改同一行代码），尽早熔断。
逻辑：检测连续 3 次 Tool Call 失败或相似度极高，直接由规则引擎介入终止对话，提示用户人工干预，而不是让模型继续空转。节约开发时间。目前业务开发应该还不用太关注，但是能节约公司成本。
番外篇：颠覆性的产品思维
”AI 浏览器”是一个被移动互联网思维限制的伪命题
浏览器是工具，不该是容器
共识： 浏览器是互联网的入口，AI 应该作为浏览器的一个超级插件或新形态（如 Arc Search），增强人的搜索和阅读体验。
Manus： 浏览器不应该是 AI 的”家”，而应该是 AI 的”手”。
季逸超认为，把 AI 塞进浏览器（Sidepanel/Sidebar）是在做”加法”，本质上还是”人自己在上网，AI 在旁边提建议”。
真正的 Agent 应该是代替人去使用浏览器。在 Manus 的架构里，浏览器只是一个被调用的”工具”（Tool），就像 Python 解释器、Excel 一样平级。
比喻：如果你雇了一个秘书，你不会把秘书关在浏览器里，而是希望秘书能自由地打开浏览器查资料、打开 Word 写文档、打开微信发消息。
“阅读” vs “行动”
AI 浏览器的局限： 目前的 AI 浏览器（如 Perplexity, Arc）主要解决的是 Read（信息获取）的问题——总结网页、提取答案。
Manus 的目标： 解决 Act（行动交付）的问题。
他们发现，用户真正想要的不是”更快的搜索”，而是”把活干完”。例如：用户不需要 AI 告诉他”去哪个网站买票”，而是需要 AI 直接把票买好。要做到这一点，AI 必须跳出浏览器的框框，拥有操作系统的权限（文件读写、多应用调度）。
商业模式：从”卖流量”到”卖劳动力”
互联网逻辑（浏览器）： 追求 DAU（日活）、时长、点击率。因为软件边际成本为零，所以要尽可能多地卷入用户。
制造业逻辑（Manus）： AI 更像制造业，Token 是原材料，算力是电费。
季逸超反复强调，AI 的每一次推理都有刚性成本。如果只是做一个浏览器插件陪聊，很难覆盖高昂的推理成本（尤其是当你追求极致效果使用 GPT-4o 等大模型时）。
结论：必须做高价值交付。只有当 AI 帮你完成了一项耗时 2 小时的复杂工作（比如写了一份研报、修了一个 Bug），你才愿意为此支付比电费高得多的溢价。Manus 不卖”对话”，卖的是”数字劳动力”。
技术哲学：通用性（General）> 垂直优化
业界： 做垂直 Agent（如专门写代码的 Devin、Cursor、专门写文案的 Jasper）。
Manus： 通用本身就是一种能力。
他们认为，真实的工作流是高度碎片化且跨域的。一个程序员修 Bug，可能需要去 Google 查文档（浏览器）、去 GitHub 看代码（代码工具）、去 Slack 问同事（通讯工具）。如果只做一个”代码 Agent”，它在需要查文档时就卡住了。
因此，Manus 必须是一个 General Agent，它像人一样，虽然不是每个领域都精通，但具备”学习使用任何工具”的能力。不去做每个垂直领域的专家，也卷不过专业原生领域的工具，做一个使用工具全能的手。
延伸阅读
- Manus季逸超访谈解读
- 深读 Manus：寻找 Agent 产品的”品味”与”定力”
- Manus 团队访谈合集