#Agent

决定 Agent token 效率的变量不只有模型和提示词，还包括Agent面对的操作界面(Interface/Surface)。

说「Agent 想要文件系统」，听上去像拟人化。更准确地说，是今天的大语言模型在训练数据、后训练任务和工具生态里，反复学到了一套非常稳定的工作模式：进入目录 → 列文件 → 搜关键词 → 打开局部内容 → 引用具体行号。

文件系统语义对 Agent 友好，主要不是因为「文件」这个存储介质，而是因为它提供了一种 progressive disclosure（渐进式披露）的交互方式：

• 先低成本发现：ls看有哪些东西，stat看对象卡片，catalog看可查询字段。
• 再按需读取：只有找到目标后，才用read打开内容。
• 搜索可以限定范围：全局grep用来发现线索，目录内grep用来提取证据。
• 路径是稳定句柄：/runs/abc/stdout.log 既是名字，也是后续继续操作的地址。

相比之下，SQL 更像是要求 Agent 先理解一张地图，然后一次性写出正确路线。对于清晰的结构化聚合，这很强；但对于「先找 cohort（样本组），再查日志，再引用证据」的复合探索任务，前置认知成本会变高。

Agent擅长搜索有名字、有层级、可局部打开的空间

很多人谈token成本时，只看输入prompt有多长、输出回答有多长。但对具备推理能力的模型来说，每个工具调用轮次里的一部分预算会花在「我现在看到了什么、下一步该查哪里、这些字段之间怎么关联、刚才的结果是否足够回答问题」上。换句话说Agent不只是在读取数据，它还在不断维护一张临时的任务地图。

如果接口迫使Agent先理解复杂schema、猜join路径、拼blob_ref、回忆哪些id对应哪些日志，那么模型的注意力就会被大量消耗在「拼上下文」和「找路」上。它虽然还在工作，但越来越像一个人一边翻十几张表、一边记临时编号、一边担心自己有没有漏掉关键字段。这种状态下，token不是被花在真正的判断上，而是被花在维持工作记忆上。

文件系统形态的接口会减轻这种负担。路径本身就是稳定句柄，目录天然表达范围，grep返回的是带位置的证据，find和aggregate可以把过滤、排序、limit和字段投影下推给系统Agent不需要在脑子里反复重建「数据在哪里」，而是可以顺着路径逐步缩小搜索空间

一般来讲，只要一个智能体系统高度依赖大量文件、日志、报告、模型、合同、图片、音视频、checkpoint 等外部产物，就会遇到类似问题。可以把这类系统称为 artifact-heavy（产物密集型）Agentic 系统

今天的训练、评测和推理系统会产生大量run、trace、日志、模型checkpoint、指标和配置。作为人的我们会问：「哪组配置最好？」「这批失败任务为什么取消？」「这个采样run到底加载了哪个模型？」这些问题往往不是一条SQL能解决的，而是要在结构化指标、非结构化日志和 artifact 元数据之间来回探索。

从 token efficiency 的角度看，这是一种很差的接口选择：Agent的预算被花在「我该去哪找这份文件、哪个版本才是当前版本、这个摘要对应哪段原文」上，而不是花在法律分析、实验判断或业务决策上。

这就是研究人员认为「文件系统语义」会重新变重要的原因–LLM 被训练得非常擅长在这种形态的空间里工作。

用 AI 操作 PowerPoint 去做 PPT 的思路本身不 AI Native，不是说不能操作 PowerPoint，而是做出来不好看，因为目前的 AI 没办法通过“操作”的方式去做出好看的 PPT，它擅长的还是生成。

像 Kimi 那样发明一种 YAML 的中间格式 PPTD (PPT-DSL)，可行，但还不够好。有两个问题：

1. 这种格式没有足够的训练，需要大量的额外说明，所以 Kimi 用了将近 2000 行文档来说明什么是 PPTD，另外这种 YAML 格式本身表达力有限，难以表达完整的格式
2. 不够美观，现在模型设计能力越来越好，但是对于非标准格式效果要大打折扣，模型做设计最熟悉的是 HTML 格式。

也有人说，用模板是不是就可以解决美观的问题。

用模板部分解决了美观问题，但问题是选择会很有限，反而是限制了模型的想象力。

不要忘记《苦涩的教训》：

长期来看，依靠大规模算力和通用学习方法的“笨办法”，终将战胜依赖人类专家知识的“聪明捷径”。

换句话说，与其内置一堆模板，不如让模型自己发挥。

目前 AI 做 PPT 的最佳实践应该是 Claude Design 采用的模式：

• 用 Design System 定义好设计风格
• 使用 HTML 生成网页 PPT
• 将 HTML 导出成可编辑的 PPTX（PPTX 是标准格式）

HTML 可以保证大模型生成 PPT 的美观，可以人工二次编辑，又可以几乎无损（不是绝对）转成 PPTX。

这也是我学到的两条经验：

1. 让 Agent 操作它最擅长的格式
2. 给 Agent 规范，而不是模板（不是说不能用模板，而是不能过于依赖模板）

一个 2C 软件应该是面向普通老百姓设计的而非精英。如果你和很多人接触过你就会发现，大部分人是没有主动提出问题的能力的，即便要提出，也没有掌握正确的提问方式。

现在的 Agent 希望自己的能力是泛化的，所以一切功能都来自于用户的自然语言输入，而一个人的真实世界行为其实主动发起聊天是极少的场景，大部分我们的数字生活都是被动的。被动被推荐新闻短视频，被动刷 Ins 流，被动决定晚饭吃什么，正是这些被动才使得我们的生活变得轻松，主动的人生是值得追求的但是非常累。

Agent 应该是一种技术实现方法，而不是软件交互方式。

Agent 的技术原理其实很简单，就是「用户输入」-「模型推理」-「工具调用」-「模型推理」- … -「输出结果」。技术上并没有限定输入输出必须是以聊天的方式进行的。

我认为的务实的交互方式是，利用现存软件已经积累的数据资产和 UI ，在背后让软件的实现方式变成 Agent 化。

• 围绕KV缓存进行设计
  • 保持你的提示前缀稳定
  • 使你的上下文只追加
  • 在需要时明确标记缓存断点
• 遮蔽，而非移除工具
  • 随着代理能力的增强，其行动空间自然变得更加复杂——简单来说，工具数量爆炸式增长。最近流行的MCP只会火上浇油。如果你允许用户自定义工具，相信我：总会有人将数百个神秘工具插入到你精心策划的行动空间中。结果，模型更可能选择错误的行动 或采取低效的路径。简而言之，你武装过度的代理变得更加愚蠢。
  • 一个自然的反应是设计一个动态行动空间——可能是使用类似于RAG的方法按需加载工具。但我们的实验表明了一个明确的规则：除非绝对必要，避免在迭代过程中动态添加或移除工具
    • 在大多数LLM中，工具定义在序列化后位于上下文的前部，通常在系统提示之前或之后。因此任何更改都会使后续所有动作和观察的KV缓存失效。
    • 当先前的动作和观察仍然引用当前上下文中不再定义的工具时，模型会感到困惑。如果没有约束解码，这通常会导致模式违规或幻觉动作。
  • 大多数模型提供商和推理框架支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束动作空间
• 使用文件系统作为上下文
  • 压缩策略始终设计为可恢复的
• 通过复述操控注意力
  • 通过不断重写待办事项列表，Manus将其目标复述到上下文的末尾。这将全局计划推入模型的近期注意力范围内，避免了"丢失在中间"的问题，并减少了目标不一致。实际上，它使用自然语言来使自己的注意力偏向任务目标——而不需要特殊的架构变更。
• 保留错误的内容
  • 代理会犯错。这不是bug——这是现实。语言模型会产生幻觉，环境会返回错误，外部工具会出现异常行为，意外的边缘情况随时都会出现。在多步骤任务中，失败不是例外；它是循环的一部分。
  • 根据我们的经验，改善代理行为最有效的方法之一出奇地简单：将错误的尝试保留在上下文中。当模型看到一个失败的行动——以及由此产生的观察结果或堆栈跟踪——它会隐式地更新其内部信念。这会改变其先验，降低重复相同错误的可能性。 事实上，我们认为错误恢复是真正代理行为的最明显指标之一。然而，在大多数学术工作和公共基准测试中，这一点仍然代表性不足，它们通常关注理想条件下的任务成功。
• 不要被少样本示例所困
  • 少样本提示是提高LLM输出的常用技术。但在代理系统中，它可能会以微妙的方式适得其反。语言模型是优秀的模仿者；它们模仿上下文中的行为模式。如果你的上下文充满了类似的过去行动-观察对，模型将倾向于遵循该模式，即使这不再是最优的。
  • 解决方法是增加多样性。Manus在行动和观察中引入少量的结构化变化——不同的序列化模板、替代性措辞、顺序或格式上的微小噪音。这种受控的随机性有助于打破模式并调整模型的注意力。
  • 不要让自己陷入少样本学习的窠臼。你的上下文越单一，你的智能体就变得越脆弱。

Memory: 让正确的过去，在正确的时候，以正确的作用域，正确的方式重新出现。

记忆功能常被产品宣传为“越用越懂你”。更准确地说，它解决的是重复交代背景的问题：用户长期使用某个 AI 产品后，一些背景和历史不希望反复交代。模型本身没有长期记忆，产品要做的是从历史交互中提取少量可信信息，用于理解用户和延续任务。

和记忆相关的内容有三类：

• 聊天历史（事情发生过，但不一定该影响未来，可作为 RAG 检索源）
• 当前工作空间的工作记忆（项目进度）
• 长期记忆 Memory（在用户发当前任务之前，默认就能代入上下文、影响结果走向的内容）

关键在于：Memory 系统要做一次准入判断——哪些历史信息可以继续影响未来要做的任务。

以上五类记忆都属于陈述性记忆（declarative memory），记录的是“用户是谁、了解什么、发生过什么”，也就是用户特征、知识背景和历史交互。它们提供的是推理前提，不直接规定 Agent 该怎么做事。WorkBuddy 没有把 Procedural Memory（程序性记忆）纳入长期记忆，是因为程序性记忆记录的是“做事方法”，这类内容一旦作为长期记忆注入，会直接影响 Agent 的推理路径和执行顺序。

例如“用户熟悉 Python”是陈述性信息；“遇到所有调试任务，都先重启服务再查日志”是程序性策略。后者注入上下文后会带来几个问题：

• 局部经验被误升为通用策略：一次任务里有效的步骤，换个项目未必成立；
• 干扰模型推理：模型可能不再根据当前证据选路径，而是复用历史步骤，陷入局部最优；
• 隐性改写 Agent 行为：程序性内容实际上接近动态 System Prompt，却可能缺少版本、评测、审批和回滚；
• 降低泛化与可控性：如果 Agent 从每次任务自动学工作流，又没有稳定的奖励信号和 Eval，系统很难判断它是在改进还是在积累偏见。

Memory 系统按稳定事实、用户知识背景、行为信号、表达偏好和会话延续信息分层存储，仅陈述性记忆进入长期记忆。程序性记忆（做事方法）不纳入长期记忆，以免局部经验被误升为通用策略；验证过的工作方法以 Skill 形式版本化、可评审、可回滚。