在很早以前，人们只要有Know What就可以找到一份工作，比如你知道CPU的原理，那么你应该可以加入仙童半导体来设计CPU、针对80386来编写汇编程序；后来技术不断进步，计算机领域变得广大，互联网容纳了大量的就业人口——因为需要这么多劳动力进行代码生产，而代码运行的边际效应递减，成为了新时代的金矿。在这个时候，人们需要Know How来获得一份工作，于是出现了各种各样的面经和面试框架，来让人们孔雀开屏一样展示自己的“能力”。

现在，由于知识获取的门槛大幅度降低，考察Know How已经意义不大了，至少应用领域的程序员如此，我相信不久之后（或许现在已经如此），系统领域的程序员也会有类似的感觉。于是我把视线转向了Know Why：重点不是你知道做法，而是你知道为什么这么做，其中的技术演进和取舍是什么，以及最重要的，这其中你自己的实践与思考是什么。

这是因为，我觉得我们通过LLM已经逐渐找到了一种能够更具效率地进行生产活动的方式，也就是新的生产工具，我反对声称人们是珍妮纺纱机的操作员，因为情况大不相同，真正珍妮纺纱机的操作员——那些对着纸带打字的人，早就已经被淘汰了，目前的程序员群体，应当是一群实验科学家，他们拥有自我改善工具的能力，同时使用工具进行生产活动，而在此之前，由于个人的劳动力有限，所以组织形式更倾向于劳动密集地去做一些事，比如华为大兵团、字节快节奏+拉会，以降低集体智商为代价，工业化地生产代码来获得利润，字节是最后的赢家，因为他们发现了一件事：集体智商的提高虽然增加成本，但如果能有效规模化，那么其增加的利润更加客观，因为其中的摩擦降低了，于是他们做出了大家吹嘘的“算法导向”、“数据导向”，在我看来，这只是一种为了让高智商的人能够在一个固化的地方做狗屁工作，但更具规模效应，从而产生更多利润的组织方式。

但LLM有迹象改变这件事，程序员现在可以以更快地方式构建工具，而构建的工具自身可以帮助程序员继续改进工具。于是乎，整个事情不再是以某种方式组织生产，而是在生产力大规模进步的情况下，以某种方式组织集体智商。用一个漏洞百出的公式解释这个问题：$\text{产出} = \text{人数} \times \text{集体智商} \times (1 - \text{通信损失比})$，这个公式中，人数一定会增长随着企业壮大而增长，而企业一直在解决的问题就是，人数增长的情况下，集体能不能不变成弱智，通信损失能不能更少，在这个过程中边际效应递减，最终企业成长到稳定的规模后停滞。LLM的改变在于，这个公式变成了$\text{产出} = \text{人数} \times \text{AI增益比} \times \text{集体智商} \times (1 - \text{通信损失比})$，有可能的情况是，在人数不进行大规模扩张的情况下，通过组织架构的优势，优化集体智商、AI增益，减少通信损失，来对抗边际效应递减的问题，走出所谓的平方增长曲线。其手段包括但不限于：更扁平的组织、更少的管理和工作化生产手段、更多鼓励探索和协作，最后人们有可能自主地拓宽边界，或许这是一种“反赛博朋克”。

总结来看，从现在往后的工程师，可能在技术之外还需要一种“领导力”，不是因为经济活动扩张组织架构，需要指导更多的牛马干活的字节3-1，而是在新型组织架构下，如何与不同知识背景的人共事，共同控制AI一起进行更高效的经济活动的能力。而技术活动，更多的是基于人机协作地增强自己的认知，来服务于前面新型组织对于人类智慧、沟通与协作的要求。

这个「框架」视角值得继续展开。除了「怎么用」之外，还有一个问题：如果AI Coding确实是一个框架，这个事实本身意味着什么？

人们在使用AI编程的时候，实际上是在用自然语言调用一个框架。观察一下AI Coding的使用方式：你描述意图（自然语言API），提供上下文（配置），AI根据内部机制生成代码（框架行为），你review输出（验收）。这和调用Spring、React、Rails的模式是同构的 – 区别只是接口从编程语言变成了自然语言。

一旦接受这个前提，很多关于AI编程的困惑就有了框架理论下的自然解释。

框架的铁律：抽象必然泄漏

Joel Spolsky在2002年提出的抽象泄漏定律(The Law of Leaky Abstractions)指出：所有非平凡的抽象都会在某种程度上泄漏。SQL隐藏了查询计划，但你迟早要理解索引。React隐藏了DOM操作，但你迟早要理解reconciliation。Spring隐藏了对象生命周期，但你迟早要理解Bean的作用域和循环依赖。

AI Coding也不例外。它隐藏了”把设计变成代码”的过程，但这个抽象会泄漏。而且它的泄漏方式比传统框架更棘手：

传统框架泄漏时，你有trace。 Spring抛异常时有完整的stack trace，React的DevTools能让你看到组件树和渲染周期。你知道泄漏发生了，也知道去哪里找原因。

AI Coding泄漏时，你没有trace。 它生成一段看起来正确的代码，编译通过，基本功能正常，但在某个边界条件下会静默出错。你甚至不知道泄漏已经发生了 – 直到生产环境暴露问题。这种概率性的、无信号的泄漏，比传统框架的确定性错误更难应对。

想做好饭，有了现代厨具（烤箱、空气炸锅、微波炉）以后，入门门槛降低了，但想做出真正好的菜，最终还是要理解美拉德反应、水分蒸发速率、蛋白质变性温度。厨具降低了操作门槛，没有降低原理门槛。框架也一样。

框架的API：自然语言

传统框架的API有类型签名、参数校验、返回值定义。你调错了会编译失败或抛异常。

自然语言作为API没有这些约束。同一句话在不同context下可能触发完全不同的行为。没有类型检查告诉你”你的需求描述缺少了关键参数”，没有编译器提醒你”这个意图是歧义的”。

这意味着使用AI Coding这个框架的调试成本,集中在输入侧而非输出侧。传统编程中bug出在代码里，你调试代码。AI编程中”bug”经常出在你的描述里 – 你以为说清楚了，其实有三种合理的解读，AI选了你没想到的那种。

Context engineering、AGENTS.md、rules文件 – 这些实践的本质是在为一个没有类型系统的API补充约束。它们是自然语言框架下的”类型声明”。

框架的使用效率不对称

作为生产力工具来看,AI Coding有一个反直觉的特征：它帮助强者更多,帮助弱者更少。

大多数生产力工具是反过来的。拼写检查对拼写差的人帮助更大。代码格式化工具对所有人效果差不多。这些工具的共同特征是缩小差距。

AI Coding则放大差距。有经验的开发者能快速分解任务、设定清晰的约束、评估生成代码的质量、在泄漏发生时诊断问题。他们把AI当作一个被良好配置的框架来使用，获得5-10倍的效率提升。经验较少的开发者缺乏这些能力，往往在”生成-不对-重试”的循环中消耗大量时间，效率提升远小于预期。

这恰恰是框架的行为模式，而非工具的行为模式。熟悉Spring原理的人用Spring如虎添翼，不熟悉的人被Spring折磨。这个规律在AI Coding上完全成立。

以局部、定义良好的任务来看，AI Coding确实表现为生产力工具 – “把这个函数从回调改成async/await”、”给这个接口写单元测试”，这些任务规约完整，输出容易验证，谁用谁快。但在系统级任务上 – “重构这个模块的错误处理”、”设计一个消息消费者的重试策略” – 规约天然不完整，输出的正确性依赖领域知识来判断。此时AI就是一个框架，使用者的水平直接决定产出的质量。

分界线在于：任务的规约是否完整。 规约完整时是工具，规约不完整时是框架。而大多数有价值的工作，规约天然是不完整的。

“一句话做产品”：过度抽象

“一句话做产品”是框架思维下的自然推论走到了极端：如果AI是一个可以用自然语言调用的框架，那能不能只用一句话调用一次，就得到一个完整产品？

不能。原因不是模型能力不够，而是抽象层级过高，泄漏是必然的。

产品不是由一句话定义的，而是由上万个微决策构成的。”任务逾期了怎么通知”、”用户删除数据后保留多久”、”并发编辑时冲突怎么解决”、”移动端和桌面端的交互差异”。这些不是实现细节，而是产品本身。每一个未被显式规约的决策，框架都会用默认行为填充 – 而默认行为约等于”AI对这个问题的平均想象”。

这就像你不可能用一行配置文件驱动Spring做出一个完整的业务系统。不是Spring不够强，而是那些业务规则无法被压缩进一行配置。函数签名容纳不了那么多信息。

“一句话做产品”的尝试者通常会进入一个循环：生成 -> 不是我想要的 -> 补充描述 -> 还不对 -> 再补充 -> … 这个循环的本质是在做需求分析 – 把模糊的意图逐步精确化为规约。他们没有跳过产品设计，只是换了一种方式在做产品设计，而且是一种效率很低的方式，因为自然语言没有类型系统来帮助他们发现规约中的遗漏。

复杂度守恒

框架不消灭复杂度，只搬运复杂度。这是软件工程几十年来反复验证的规律：

• 汇编到高级语言：消灭了手动内存管理的复杂度，搬到了理解垃圾回收和运行时行为上
• SQL：消灭了手写查询计划的复杂度，搬到了理解索引设计和查询优化上
• No-code平台：消灭了写代码的复杂度，搬到了平台约束和定制化困难上

AI Coding：消灭了”把设计变成代码”的复杂度，搬到了”规约是否精确”和”输出是否正确”的判断上。

每一代工具都把复杂度从操作层搬到了认知层。以前你需要能写代码（操作），现在你需要能判断代码对不对、设计合不合理（认知）。操作可以被工具替代，认知很难。

这也解释了为什么AI Coding作为框架是不对称的：操作能力的差距被工具抹平了，但认知能力的差距被暴露出来了。以前你可以通过”写出能跑的代码”来证明自己的价值，现在这一步几乎免费了，你需要通过”判断代码是否正确、设计是否合理、系统是否可靠”来证明价值 – 这些东西以前被实现成本掩盖着，现在无处可藏。

And…

回到标题。AI Coding is a framework, and:

…抽象必然泄漏。 泄漏时你需要能接住，这需要理解抽象之下的东西。

…框架放大使用者之间的差距。 善用框架需要比框架知道的更多，这在所有框架上都成立。

…一句话做不了产品。 因为产品是上万个微决策的集合，一次函数调用容纳不了这些信息。

…复杂度不会消失，只会搬家。 从操作层搬到认知层，从实现搬到规约和判断。

…理解原理变得更重要，而不是更不重要。 当实现成本趋近于零时，瓶颈暴露在设计和验证上。这些能力的根基是对系统行为、失败模式、抽象边界的理解 – 即原理。

程序员不需要恐惧AI Coding这个框架，就像不需要恐惧Spring或React一样。需要做的是理解它的工作方式、边界在哪里、什么时候会泄漏、泄漏时怎么办。这是使用任何框架的基本功。

而理解一个框架最好的方式，从来都是自己造一个。构建自己的Agent SDK、Agent CLI，哪怕只是一个简单的tool calling loop，都会让你对context window的限制、tool dispatch的成本、prompt与行为之间的映射关系有切身的体感。这种体感是任何文档和教程都给不了的。

这也是我在做ya-agent-sdk时的感受：当你亲手处理过context截断、subagent协调、tool权限控制这些问题之后，再回到使用侧，你对框架泄漏的嗅觉会完全不同。不是因为你变聪明了，而是因为你见过抽象之下的东西。

上一篇《Agent 工具发现：从上下文膨胀到按需加载》介绍了 ToolSearchToolSet——通过搜索发现并动态加载工具到模型的工具列表中。方案解决了上下文膨胀问题，但引入了一个新的工程约束：每次加载新工具都会改变工具列表，导致 Prompt Cache 失效。本文讨论这个问题的成因和一种不改变工具列表的替代方案。

问题回顾：ToolSearchToolSet 做了什么

先简要回顾上一篇的方案。ToolSearchToolSet 的核心逻辑是：

1. 初始状态下，模型只看到 tool_search 这一个搜索工具。
2. 模型调用 tool_search 发现目标工具后，SDK 将其加入工具列表。
3. 下一轮对话时，模型直接看到并调用新工具。

这个方案的优点是模型通过原生工具调用（native tool call）与工具交互，调用体验和普通工具一致。但”动态加入工具列表”这一步带来了一个成本问题。

Prompt Cache 的工作原理

理解问题之前，需要先了解 Prompt Cache 的机制。

Anthropic 和 OpenAI 都提供了 Prompt Cache 能力。核心思路是：当连续的 API 请求共享相同的前缀内容时，服务端可以缓存这部分内容的 KV Cache，后续请求跳过前缀的重新计算，降低延迟和成本。

对于 Anthropic Claude，缓存的输入 token 费用是标准价格的 10%；对于 OpenAI，缓存命中时输入 token 费用减半。对于长上下文的 Agent 应用来说，这是一个显著的成本差异。

缓存命中的前提是前缀完全一致。以 Anthropic Claude 为例，一次 API 请求的前缀结构是：

1

[Tool Definitions] + [System Prompt] + [Conversation History...]

工具定义排在最前面。这意味着工具列表一旦发生变化——哪怕只是新增了一个工具——从变化点开始，System Prompt 和整个对话历史的缓存全部失效。

动态工具列表为什么破坏缓存

ToolSearchToolSet 的工作流程中，工具列表在运行时变化：

sequenceDiagram    participant App as Application    participant API as LLM API    Note over App,API: Turn 1: tools = [tool_search]    App->>API: Request with 1 tool defined    API-->>App: call tool_search, query=github    Note over App,API: Turn 2: tools = [tool_search, create_issue, list_repos, ...]    App->>API: Request with N tools defined    Note right of API: Tool list changed, cache miss from tool defs onward    API-->>App: call create_issue

Turn 1 的请求缓存了 [System Prompt] + [tool_search definition] 这段前缀。Turn 2 的工具列表变成了 [tool_search, create_issue, list_repos, ...]，前缀从工具定义部分开始就不同了。之后对话历史中积累的所有 token 都无法命中缓存。

对于长对话的 Agent（比如一个编程 Agent 可能一次会话有 50-100 轮对话、100K+ token 上下文），每次工具发现都触发缓存失效，累积的成本开销不可忽略。

更具体地量化：假设一个 Agent 会话在发现工具后还有 80K token 的对话历史。如果使用 Anthropic Claude，缓存命中时这 80K token 的输入费用是标准价的 10%。缓存失效意味着每次请求都要按全价计算这 80K token。对于一个每天处理上千个会话的系统，差异会体现在账单上。

ToolProxyToolset：固定工具列表的方案

解决思路直接：不改变工具列表。

ToolProxyToolset 把所有外部工具藏在两个固定的代理工具背后：

• search_tools: 搜索可用工具，返回工具名称、描述和完整参数 Schema
• call_tool: 通过名称调用任意已发现的工具

工具列表始终是 [search_tools, call_tool]，不会因为发现新工具而变化。

sequenceDiagram    participant Model    participant Proxy as ToolProxyToolset    participant MCP as MCP Server    Note over Model,Proxy: Tool list: [search_tools, call_tool] (fixed)    Model->>Proxy: search_tools(query="github issues")    Proxy->>Proxy: Keyword/Embedding search    Proxy-->>Model: XML with tool schemas    Model->>Proxy: call_tool(name="create_issue", arguments={...})    Proxy->>MCP: create_issue({repo: "...", title: "..."})    MCP-->>Proxy: {issue_url: "..."}    Proxy-->>Model: {issue_url: "..."}    Note over Model,Proxy: Tool list still: [search_tools, call_tool]

模型不再直接调用 create_issue，而是通过 call_tool 间接调用。工具定义前缀从始至终不变，Prompt Cache 始终命中。

search_tools 的信息传递

工具列表不变，意味着模型永远不会在工具定义中看到目标工具的 Schema。那模型怎么知道如何构造参数？

答案是 search_tools 的返回值中包含完整的参数 Schema。结果以 XML 格式返回：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<search-results query="github issues" count="3">
<tool name="create_issue" namespace="github">
  <description>Create a new issue in a repository</description>
  <parameters>{"type": "object", "properties": {"repo": {"type": "string"}, "title": {"type": "string"}, "body": {"type": "string"}}, "required": ["repo", "title"]}</parameters>
</tool>
<tool name="list_issues" namespace="github">
  <description>List issues in a repository</description>
  <parameters>{"type": "object", "properties": {"repo": {"type": "string"}, "state": {"type": "string", "default": "open"}}, "required": ["repo"]}</parameters>
</tool>
<tool name="close_issue" namespace="github">
  <description>Close an existing issue</description>
  <parameters>{"type": "object", "properties": {"repo": {"type": "string"}, "issue_number": {"type": "integer"}}, "required": ["repo", "issue_number"]}</parameters>
</tool>
</search-results>

模型从这段对话内容中读取 Schema，然后构造 call_tool 调用。Schema 信息在对话历史中而不在工具定义中——对话历史本身不会影响前缀缓存的有效性（对话历史追加在前缀之后）。

错误处理与自修正

原生工具调用时，参数校验由框架（pydantic-ai）自动完成，模型收到的是结构化的验证错误。ToolProxyToolset 中，工具调用通过 call_tool 代理，校验逻辑由代理层捕获并转换为 XML 格式的错误信息：

1
2
3
4

<tool-call-error tool="create_issue">
  <message>Missing required argument: repo</message>
  <parameters>{"type": "object", "properties": {"repo": {"type": "string"}, "title": {"type": "string"}}, "required": ["repo", "title"]}</parameters>
</tool-call-error>

错误信息中附带完整的参数 Schema，模型可以据此修正参数并重试。实践表明，主流模型（Claude、GPT-4o）在看到这种结构化错误后的修正成功率与原生验证错误基本一致。

跳过搜索直接调用

call_tool 不要求模型必须先搜索。如果模型已经知道工具名称和参数（比如从对话上下文、历史搜索结果、或 Session 恢复后的动态指令中获知），可以直接调用：

1

call_tool(name="create_issue", arguments={"repo": "org/repo", "title": "Bug fix"})

这避免了”搜索 -> 调用”的强制两步流程。在 Session 恢复场景中，ToolProxyToolset 通过动态指令列出之前已发现的工具摘要，模型看到摘要后可以直接发起 call_tool，不需要重新搜索。

与 ToolSearchToolSet 的权衡

两种方案并非简单的替代关系，而是不同约束下的不同选择。

flowchart LR    subgraph ToolSearchToolSet        A1[tool_search] --> A2[Dynamic tool list]        A2 --> A3[Native tool call]        A3 --> A4[Cache invalidated on discovery]    end    subgraph ToolProxyToolset        B1[search_tools] --> B2[Fixed tool list]        B2 --> B3[Proxy via call_tool]        B3 --> B4[Cache always stable]    end

核心权衡是 Cache 稳定性 vs. 模型交互简单性。

ToolSearchToolSet 对模型更友好——模型直接看到工具定义并原生调用，这是 LLM 训练时最常见的交互模式。ToolProxyToolset 要求模型理解”通过一个间接层调用工具”的模式，这对较弱的模型可能是个挑战。

但对于成本敏感的生产系统，ToolProxyToolset 的 Cache 稳定性带来的成本节省往往更重要。尤其是当 Agent 接入大量 MCP Server、单次会话上下文较长时，Cache 命中率的差异会直接体现在延迟和费用上。

选择建议

基于上述分析：

选 ToolProxyToolset 的场景：

• MCP Server 数量多、工具总数大（30+）
• 单次会话上下文长（50K+ token）
• 成本敏感，需要最大化 Prompt Cache 命中率
• 使用的模型能力强（Claude Sonnet/Opus、GPT-4o），能可靠处理代理调用模式

选 ToolSearchToolSet 的场景：

• 工具数量适中（10-30），发现行为不频繁
• 使用较小的模型，代理模式可能导致调用错误率上升
• 会话较短，Cache 失效的成本影响有限
• 优先考虑调用可靠性而非成本优化

10 个以下工具：两种方案都不需要。直接全部加载到工具列表即可。

实现细节

ToolProxyToolset 复用了 ToolSearchToolSet 的基础设施：

• SearchStrategy 接口：相同的 KeywordSearchStrategy 和 EmbeddingSearchStrategy，可互换。
• ToolMetadata：相同的工具元数据提取逻辑。
• AgentContext 状态字段：tool_search_loaded_tools 和 tool_search_loaded_namespaces，两种方案共享状态存储，甚至可以在两种方案之间切换而不丢失已发现的工具状态。
• Namespace / Loose 加载：相同的原子加载语义。
• Optional Namespaces：相同的可选命名空间机制，适配不稳定的 MCP Server。

新增的设计点：

• 动态指令（Dynamic Instructions）：ToolProxyToolset 生成包含命名空间列表、已发现工具摘要的动态指令，注入到 System Prompt 中。以 Anthropic 为例，Tool Definitions 排列在 System Prompt 之前，因此 System Prompt 的变化不会破坏工具定义部分的缓存前缀。（System Prompt 的变化会影响其之后的对话历史缓存，但工具发现通常发生在会话早期，后续轮次中指令保持稳定。）
• XML 格式的搜索结果和错误信息：选择 XML 而非 JSON，是因为 XML 的标签结构对模型的解析更友好，在对话上下文中的可读性也更好。

延伸：Code Execution 方案——更激进的思路

Anthopic 在 2025 年 11 月发表了一篇工程博客 Code execution with MCP，提出了一个更激进的方案来解决同一类问题。

其核心思路是：不让模型通过工具调用（tool call）与 MCP 交互，而是让模型写代码来调用工具。MCP Server 的每个工具被映射为文件系统上的一个 TypeScript 函数，模型通过浏览文件系统发现工具定义，然后编写代码在沙盒中执行。

sequenceDiagram    participant Model    participant Sandbox as Code Sandbox    participant MCP as MCP Servers    Model->>Sandbox: Write code to call gdrive.getDocument    Sandbox->>MCP: getDocument documentId=abc123    MCP-->>Sandbox: Full document content, 10K words    Sandbox->>Sandbox: Filter and transform data in code    Sandbox-->>Model: Processed summary, 50 words

这个方案解决了 ToolProxyToolset 没有解决的一个问题：中间结果膨胀。

在 ToolProxyToolset 中，call_tool 的返回值仍然完整地回流到模型上下文。如果一个工具返回了 10K 行的表格数据，模型会看到全部内容。而在 Code Execution 方案中，模型可以在沙盒里执行 filter、map、slice 等操作，只把处理后的结果返回给自己。Anthropic 的文章举了一个例子：10,000 行表格经过代码过滤后，模型只看到 5 行。

此外，Code Execution 方案还支持组合调用——一段代码中可以串联多个工具调用，中间结果在沙盒内流转而不经过模型。这进一步减少了上下文消耗和模型推理轮次。

ToolProxyToolset 与 Code Execution 的对比

两种方案并不互斥。ToolProxyToolset 解决的是工具定义层面的问题（定义膨胀、Cache 失效），Code Execution 解决的是执行层面的问题（中间结果膨胀、多步编排）。一个可能的组合方式是：用 ToolProxyToolset 做工具发现和 Schema 管理，用 Code Execution 做实际调用和数据处理。

但 Code Execution 方案的工程成本也更高。安全沙盒的构建和维护（资源限制、网络隔离、超时控制）是一个独立的基础设施问题。

编程 Agent 已经是 Code Execution 环境

仔细审视 Anthropic 描述的 Code Execution 方案，会发现一个有趣的事实：它所构建的能力，编程 Agent 已经天然具备了。

把 Anthropic 方案的核心要素逐一对应：

一个拥有 Shell 访问权限和 Skills 系统的编程 Agent，本身就是一个代码执行环境。它不需要额外构建沙盒来”将 MCP Server 呈现为代码 API”——它可以直接写一个脚本调用 MCP Server 的 CLI 工具，用管道过滤数据，把结果存到文件里供后续使用。这些都是 Shell 环境的原生能力。

这指向一个更深层的架构观察：Anthropic 的 Code Execution 方案本质上是在给 MCP 打补丁，试图让工具调用协议接近编程环境的表达能力。而编程 Agent 从一开始就选择了正确的抽象层次——模型就是一个有环境访问权限的程序员，工具交互只是它编程能力的自然延伸。

MCP 作为工具协议，解决的是”如何标准化地连接工具”的问题。但当工具数量增长到需要 progressive disclosure、code execution、skills 等机制来管理时，问题的本质已经从”工具连接”变成了”环境交互”。在这个层面上，Shell + 文件系统 + Skills 是一个更自然、更成熟、更通用的抽象。

这不是说 MCP 没有价值。MCP 在标准化工具接口、跨语言互操作方面仍然重要。但对于编程 Agent 来说，与其在 MCP 上层叠加越来越多的补丁机制（Tool Search、Tool Proxy、Code Execution sandbox），不如直接利用 Agent 已有的编程能力来处理工具发现、数据过滤和多步编排。ToolProxyToolset 解决的 Prompt Cache 问题是一个纯粹的 LLM API 层面的工程约束，它和工具交互的抽象层次无关，所以仍然有独立存在的价值。

写在最后

ToolProxyToolset 的实现在 ya-agent-sdk PR #53。yaacli（ya-agent-sdk 的 CLI 运行时）已经从 ToolSearchToolSet 切换到 ToolProxyToolset 作为默认的 MCP 工具管理方案。

两种方案不是互斥的。在同一个 SDK 中提供两种选择，开发者可以根据自己的模型能力、成本约束和工具规模选择合适的方案。这也是客户端实现工具管理的优势——选择权在开发者手中，而不是被厂商的 API 设计锁定。

关注本站 RSS，我会持续分享 Agent 构建过程中的架构思路和工程实践。

当 Agent 接入 5 个 MCP Server、200+ 工具时，光工具定义就能吃掉 55K token。工具多了选不准，上下文还不够用。这篇文章聊聊各家怎么解决这个问题，以及如何在 SDK 层做到供应商无关。

问题：工具规模与上下文窗口的矛盾

Agent 应用从”聊天机器人”演进到”工具调用代理”之后，核心约束从”对话质量”转向”工具管理”。一个典型的企业级 Agent 可能同时接入 GitHub、Slack、Sentry、Grafana、数据库等多个服务，每个服务暴露 10-50 个工具函数。

这带来两个工程问题：

1. 上下文膨胀。每个工具的 JSON Schema 定义占 200-500 token，200 个工具就是 40K-100K token。在 200K 上下文窗口的模型里，还没开始做事就用掉了一半预算。
2. 选择精度下降。实践表明，当可用工具数超过 30-50 个时，模型正确选中目标工具的概率显著下降。工具越多，噪声越大。

这两个问题互相加强：工具多导致上下文长，上下文长又进一步稀释模型对单个工具描述的注意力。

解决思路是一致的：按需加载（on-demand loading）。不把所有工具定义塞进初始上下文，而是让模型在需要时通过搜索发现并加载工具。

厂商方案：Anthropic 与 OpenAI 的 Tool Search

Anthropic 和 OpenAI 都在 2025 年推出了各自的 Tool Search 功能。它们的核心思路相同，但在实现细节和架构选择上有差异。

共同的设计模式

两家方案共享一个基本流程：

sequenceDiagram    participant Client as Application    participant API as LLM API    participant Search as Tool Search    participant Model as LLM    Client->>API: 请求（tools 含 tool_search + deferred tools）    API->>Model: 仅注入 tool_search + 非 deferred 工具    Model->>Search: 调用 tool_search（query）    Search-->>Model: 返回匹配的 3-5 个工具定义    Model->>Client: 调用已发现的工具

关键概念：

• defer_loading: 标记工具为”延迟加载”。初始请求时模型看不到这些工具的完整定义。
• tool_search: 一个特殊的内置工具。模型通过调用它来搜索和加载延迟工具。
• tool_reference: 搜索结果的引用。API 自动将引用展开为完整的工具定义。

Anthropic 的方案

Anthropic 提供两种搜索变体：

搜索在服务端执行。客户端只需要在 tools 列表中声明 tool_search 工具和带 defer_loading: true 的工具定义，API 在一次请求内完成搜索、展开和调用。

Anthropic 同时支持 MCP 集成。可以对 MCP Server 的所有工具设置 defer_loading 默认值，并对个别工具单独覆盖。这意味着整个 MCP Server 可以作为一个延迟加载单元。

Anthropic 也支持客户端自行实现搜索逻辑：返回 tool_reference 类型的 content block 即可，API 会自动展开引用。

OpenAI 的方案

OpenAI 的设计引入了两个额外概念：

Namespace。工具可以按命名空间分组。模型初始只看到 namespace 的名称和描述，搜索时按 namespace 为单位加载。这比逐个工具加载更节省 token，也更符合”一个 MCP Server 对应一个 namespace”的直觉。OpenAI 建议每个 namespace 不超过 10 个工具。

Hosted vs Client-executed。OpenAI 明确区分了两种执行模式：

• Hosted: 工具定义全部在请求中声明，搜索由 OpenAI 服务端执行。模型在单次请求内完成搜索和调用。
• Client-executed: 模型输出 tool_search_call，客户端自行执行搜索逻辑，返回 tool_search_output。适用于工具库动态变化、依赖租户状态等场景。

两种模式的区别在于搜索逻辑的控制权：Hosted 模式省事但不灵活，Client-executed 模式灵活但需要额外的请求轮次。

厂商方案的局限

两家方案都解决了上下文膨胀问题，但存在一个共同的结构性限制：供应商锁定。

• 搜索协议是各家私有的。Anthropic 用 server_tool_use + tool_search_tool_result，OpenAI 用 tool_search_call + tool_search_output，两者不兼容。
• 工具定义的延迟加载标记（defer_loading）嵌入在各自的 API 参数中。
• 服务端搜索的索引算法不透明，无法定制。
• 如果你的 Agent 需要在 Anthropic 和 OpenAI 之间切换（或同时使用多个 provider），工具管理逻辑需要写两套。

这个问题不仅存在于 Tool Search。Web Search、Code Interpreter、Computer Use 等”增强工具”都有类似的供应商耦合。每家厂商都在往 API 里塞越来越多的内置能力，而这些能力的接口互不兼容。

SDK 方案：客户端实现 Tool Search

另一条路线是在 SDK（客户端）层面实现 Tool Search，完全绕开厂商的服务端搜索。这是 ya-agent-sdk 的 ToolSearchToolSet 所采取的方式。

基本思路

不依赖任何厂商的 Tool Search API。把 tool_search 实现为一个普通的客户端工具函数，对模型而言它和 read_file、run_shell 没有区别。

sequenceDiagram    participant Model as LLM (any provider)    participant SDK as ToolSearchToolSet    participant Strategy as SearchStrategy    participant Toolsets as Wrapped Toolsets    Note over Model,SDK: Turn 1: 模型只看到 tool_search    Model->>SDK: call tool_search({query: "github issues"})    SDK->>Strategy: search("github issues", candidates)    Strategy-->>SDK: [github namespace matched]    SDK->>SDK: 标记 github namespace 为已加载    SDK-->>Model: "Found: [github] 3 tools loaded"    Note over Model,SDK: Turn 2: 模型看到 tool_search + github 工具    Model->>SDK: call create_issue({repo: "...", title: "..."})    SDK->>Toolsets: 转发到 github toolset    Toolsets-->>Model: {issue_url: "..."}

核心差异：搜索发生在客户端进程内，不经过 LLM API 服务端。模型只是调用了一个返回文本结果的普通工具。下一轮对话时，SDK 的 get_tools() 方法动态返回已加载的工具列表。

Namespace 与 Loose 加载

SDK 支持两种加载粒度：

Namespace 加载对应的直觉是：一个 MCP Server 是一个原子单元。如果模型需要用 GitHub 的某个工具，大概率也需要同一 Server 下的其他工具。Loose 加载适用于零散的工具函数。

可插拔的搜索策略

搜索算法不是硬编码的。SDK 定义了 SearchStrategy 协议，内置两种实现：

KeywordSearchStrategy（默认）。零外部依赖。对工具名称、描述、参数名做正则匹配，按命中位置加权打分。适合工具命名规范的场景。

EmbeddingSearchStrategy。基于 FastEmbed 的本地向量搜索。把工具元数据编码为向量，用余弦相似度排序。适合自然语言查询和语义模糊匹配。依赖约 50MB 的 ONNX 模型，CPU 上单次查询约 5ms。

还有一个 create_best_strategy() 工厂函数：优先尝试 Embedding 策略，如果 fastembed 未安装则自动降级到 Keyword 策略。

开发者也可以实现自己的策略，比如基于远程向量数据库的搜索、基于 LLM 的重排序等。

Session Restore

已加载的工具状态持久化在 AgentContext 中，通过 ResumableState 跨会话恢复。恢复会话时，之前加载过的工具和 namespace 立即可用，不需要重新搜索。

这意味着工具发现的结果可以跨越多轮对话甚至多次会话存活。

三种方案的对比

更广泛的问题：供应商锁定

Tool Search 只是一个缩影。类似的供应商耦合模式出现在多个领域：

Web Search。Anthropic 有内置的 web search tool，OpenAI 有 web search connector。两者的输入输出格式不同，搜索引擎不同，结果质量也不同。如果你在 SDK 层把 web search 实现为一个普通工具（调用 Google/Bing/SearxNG API），就完全不依赖厂商的内置能力。

Code Interpreter。两家都提供沙盒代码执行环境，但执行环境的配置、可用库、超时策略都不同。SDK 方案是启动自己的沙盒容器（E2B、Docker 等）。

Computer Use / Browser。Anthropic 的 Computer Use 和 OpenAI 的 Computer Use 接口不兼容。SDK 方案是对接 Playwright 或 Browser MCP Server。

MCP 本身。虽然 MCP 是一个开放协议，但两家厂商对 MCP 的集成方式不同——Anthropic 在 API 层支持 mcp_servers 参数直连，OpenAI 通过 Responses API 的 connector 机制接入。SDK 层面则通常直接管理 MCP Client 的生命周期。

这些案例指向一个工程决策：把供应商特有的能力转化为 SDK 层面的可替换实现。

flowchart TB    subgraph Vendor["Vendor-Specific (locked)"]        A1[Anthropic Tool Search]        A2[OpenAI Tool Search]        A3[Anthropic Web Search]        A4[OpenAI Web Search]    end    subgraph SDK["SDK Layer (portable)"]        B1[ToolSearchToolSet]        B2[WebSearchToolSet]        B3[BrowserToolSet]        B4[CodeExecToolSet]    end    subgraph Provider["Pluggable Providers"]        C1[Anthropic API]        C2[OpenAI API]        C3[Local / OSS Model]    end    SDK --> Provider    Vendor -.->|vendor coupling| Provider

这不是说厂商的方案没有价值。服务端 Tool Search 省去了客户端的计算和索引维护开销，对小团队来说是合理的选择。但当你的系统需要：

• 跨多个 LLM Provider 工作
• 定制搜索算法（比如租户级别的工具权限过滤）
• 在离线/私有化部署环境运行
• 控制工具发现的确定性行为

客户端实现就成为更稳健的架构选择。

工具管理的实践建议

基于以上分析，给出几条工具管理的实践建议：

1. 10 个工具以下不需要 Tool Search。工具少的时候，全部加载到上下文反而更简单，模型选择准确率也足够高。

2. 高频工具常驻，低频工具按需加载。把 3-5 个核心工具（如文件读写、Shell 执行）直接注册，其余工具通过 Tool Search 按需发现。

3. 按服务边界划分 Namespace。一个 MCP Server或一套工具集 对应一个 Namespace。Namespace 描述写清楚这组工具能做什么，不需要列举具体工具名。模型根据描述决定是否加载。

4. 工具描述是搜索质量的关键。无论用哪种搜索策略，工具的 name 和 description 都是最重要的检索信号。命名用 verb_noun 格式（如 create_issue、search_papers），描述用一句话说明输入输出。

5. 搜索策略按场景选择。工具命名规范、数量可控时，Keyword 策略就够了。工具来自多个第三方 MCP Server、命名不统一时，Embedding 策略更鲁棒。

6. 评估供应商耦合的成本。如果你的产品只用一家 LLM Provider 且不打算换，用厂商的内置 Tool Search 完全合理。如果你在构建需要支持多 Provider 的 SDK 或平台，客户端实现是更安全的选择。

写在最后

上述实践来自 ya-agent-sdk（PR #39），ya-agent-sdk是我积极维护的agent-sdk，用于原型创建和研究。构建于Pydantic AI之上，希望提供SOTA的上下文管理和开发体验。

关注本站 RSS，我会持续分享 Agent 构建过程中的架构思路和工程实践。

先从一个可运行的 Chatbot 服务开始：前端通过 POST /chat 发起请求，通过 GET /stream/:conversation_id 接收 SSE 事件流。
这里把职责拆成两层：

• Display Layer：向 UI 输出事件，服务展示与回放。
• Business Layer：维护消息历史，服务 prompt 构造与推理。

flowchart LR    UI[Web UI]    API[Chat Service]    LLM[LLM API]    DL[(Display Events)]    BL[(Business Messages)]    UI -->|chat request| API    API -->|sse stream| UI    API --> BL    API --> LLM    LLM --> API    API --> DL

对应的最小存储模型：

• conversation(id, created_at)
• message(id, conversation_id, role, content, created_at)

单轮写路径：

1. 接收用户输入并落库 role=user。
2. 读取最近 N 条消息构造 prompt。
3. 调用 LLM，按 token 生成 SSE 事件并写入 Display Layer。
4. 推理结束后落库 role=assistant。

sequenceDiagram    participant U as User    participant API as Chat Service    participant DB as Message Store    participant LLM as LLM API    U->>API: POST /chat    API->>DB: insert user message    API->>DB: load recent messages    API->>LLM: inference    LLM-->>API: token stream    API-->>U: SSE events    API->>DB: insert assistant message

约束保持简单：单进程、单副本、不处理并发写冲突。

下一段再进入“引入文件系统后”的架构分叉：stateless agent service + sandbox vs agent in vm。

扩展文件系统

Agent in VM

这个模式下，Agent没有多租户的概念，面对的是一台专用的虚拟机，所有多租户的概念在外部业务层实现

当 Agent 需要稳定操作本地开发环境、浏览器和长生命周期进程时，Agent in VM 是最直接的方案。
它的核心思想是：平台做“VM 分配与调度”，Agent 只面对“单租户执行环境”。

flowchart LR    U[User]    APP[Multi-tenant App]    SCH[VM Scheduler]    VM1[Tenant VM]    AG[Agent Process]    FS[(Local FS)]    SH[Shell/Browser]    LLM[LLM API]    U --> APP    APP --> SCH    SCH --> VM1    VM1 --> AG    AG --> FS    AG --> SH    AG --> LLM

设计重点：

1. 租户隔离天然清晰：每个会话绑定一台 VM。
2. 状态恢复简单：文件、进程、缓存都在 VM 内。
3. 代价是资源成本和调度时延：空闲 VM 成本高，启动/恢复慢于无状态服务。

案例：Manus、利用Claude Code SDK构建多租户agent

Stateless Agent Service + Sandbox

该方案将控制逻辑与执行环境解耦：Agent Service 保持无状态，Sandbox 承载会话执行状态。

分层如下：

• Agent Service：无状态，负责规划、路由、工具编排。
• Sandbox：有状态，负责执行命令和访问会话文件。
• Shared Storage：跨 Sandbox 挂载同一会话目录。

flowchart LR    U[User]    GW[API Gateway]    AS[Stateless Agent Service]    LLM[LLM API]    SB[Session Sandbox Pod/Lambda]    NFS[(Shared Storage)]    TOOLS[External Tools]    U --> GW --> AS    AS --> LLM    AS --> SB    SB --> NFS    SB --> TOOLS    AS --> TOOLS

可行性前提：Agentic loop 依赖“状态可引用”，不依赖“进程常驻”。只要 session 可以绑定到可恢复的文件和执行上下文，服务就可以无状态扩缩容。

关键约束：

1. 边界必须明确：哪些工具在 Agent Service 执行，哪些必须进 Sandbox。
2. 安全默认收敛：出网控制、域名/IP 白名单、速率限制、租户目录隔离。
3. 存储性能决定体验：高频读写场景要评估本地盘缓存或更高性能分布式存储。

Durable Execution（Stateless + Sandbox 的可靠性拓展）

在 Stateless Agent Service + Sandbox 中，实例漂移是常态。重试不能依赖进程内存。
Durable Execution 的目标是将一次 loop 分解为可恢复步骤，并在步骤边界写入 checkpoint。

引入原因：

1. 实例漂移是常态：Pod 重建、请求重路由都会打断内存态执行。
2. 工具调用有副作用：整轮重放会产生重复写入或重复外部调用。
3. 长任务跨多分钟：必须允许中断后继续，而不是从头开始。

最小状态拆分建议：

1. message_state：会话消息、摘要、token budget。
2. filesystem_state_ref：工作目录版本、挂载路径、快照 ID。
3. execution_state：当前 step、计划版本、上一步输出。
4. effect_log：已执行副作用记录（外部请求 ID、写操作哈希）。

flowchart LR    STEP[Run Step]    CKPT[Write Checkpoint]    EFFECT[Record Side Effect]    FAIL[Failure]    RESUME[Load Last Checkpoint]    NEXT[Run Next Step]    STEP --> CKPT    STEP --> EFFECT    STEP --> FAIL    FAIL --> RESUME    RESUME --> NEXT

实现规则：

1. 每个 step 必须可重入：相同输入重复执行，结果语义不变。
2. 每个副作用必须可去重：通过 idempotency_key 或外部事务键避免重复提交。

语义恢复

在工程实践中，很多工具调用不可回滚，或回滚成本远高于收益。
因此，失败处理可以优先采用“语义恢复”，而不是“强事务回滚”。

例如三个工具并行执行时其中一个报错，不必强制撤销其余两个工具的副作用。可采用以下策略：

1. 将消息历史恢复到这组并行工具调用之前。
2. 保留本次工具调用返回（包含不确定状态）。
3. 对失败或不确定结果注入系统说明：上次调用出错，可能已部分执行成功，请先确认状态再继续。
4. 让模型基于这条说明继续规划下一步（先确认，再补偿，或跳过）。

这里还可以向外暴露重试事件，以确保显示层不会出现未定义行为

该策略的取舍很明确：放弃严格事务语义，换取更低实现复杂度和更高恢复连续性。

Loop 级隔离编排（优化Agent Service的可扩缩容性）

这是一种中间态方案：保持 loop 代码结构不变，只隔离 loop 实例。
实现方式是“每个 turn 启动一个 Worker/Lambda”，由队列驱动执行；SSE 由事件通道异步转发到流网关。

适用原因：

1. 保持调试模型稳定：单个 loop 代码路径不变，问题定位更直接。
2. 缩小爆炸半径：单个任务异常只影响当前 worker。
3. 提升发布速度：无状态 worker 镜像可快速滚动升级。

flowchart LR    U[User]    API[Agent API]    Q[(Task Queue)]    W[Loop Worker Lambda/Pod]    LLM[LLM API]    SB[Sandbox]    EQ[(Event Queue)]    SG[SSE Gateway]    U --> API    API --> Q    Q --> W    W --> LLM    W --> SB    W --> EQ    EQ --> SG    SG --> U

实现要点：

1. turn_id 作为任务主键，保证同一轮只有一个 active worker。
2. Worker 事件写入 event queue，由 SSE gateway 统一推送，避免函数实例直接持有长连接。
3. 失败重试由队列控制，重试前先加载 checkpoint，继续执行而非整轮重跑。

在演进路径中的位置：

1. 它依赖 Durable Execution 提供可恢复状态。
2. 它不要求 Actor 拆分，适合作为高并发阶段的低改造增量方案。
3. 当单 loop 内部并发仍成瓶颈，再演进到 Actor Model。

Actor Model（优化Agent Service的可扩缩容性）

当 Stateless Agent Service 进入高并发、多工具、长链路阶段，单体 loop 的主要瓶颈是调度耦合和故障扩散。
Actor Model 是下一阶段的实现方式：将 loop 拆成可独立扩缩容的执行单元。

推荐的最小 Actor 拆分：

1. Session Actor：会话入口，维护 turn 生命周期。
2. Planner Actor：生成步骤计划与重规划。
3. Model Actor：封装模型调用策略（路由、重试、限流）。
4. Tool Actor：执行工具调用（可按工具类型分片）。
5. State Actor：集中处理 checkpoint、effect log、恢复逻辑。

flowchart LR    SA[Session Actor]    PA[Planner Actor]    MA[Model Actor]    TA[Tool Actor]    STA[State Actor]    BUS[(Message Bus)]    SA --> BUS    PA --> BUS    MA --> BUS    TA --> BUS    STA --> BUS    BUS --> SA    BUS --> PA    BUS --> MA    BUS --> TA    BUS --> STA

与前一节的关系：

1. Durable Execution 依赖 State Actor 统一写入恢复点。
2. Sandbox 调度可以下沉到 Tool Actor，实现按工具类型弹性扩缩容。
3. 故障隔离更细：单个 Tool Actor 失败不会直接拖垮整个会话调度。

代价是消息一致性、乱序处理和链路追踪复杂度上升。
建议顺序是：先稳定单体 Stateless loop，再按瓶颈引入 Actor 化拆分。

可观测性

可观测性目标不是“记录更多日志”，而是回答三个问题：慢在哪里、错在哪里、哪类任务不稳定。

flowchart LR    APP[Agent Service]    SB[Sandbox]    OBS[Telemetry Pipeline]    LOG[(Logs)]    MET[(Metrics)]    TR[(Traces)]    UI[Ops Dashboard]    APP --> OBS    SB --> OBS    OBS --> LOG    OBS --> MET    OBS --> TR    LOG --> UI    MET --> UI    TR --> UI

建议指标分两层：

1. LLM 层：QPS、TTFT、P95 延迟、错误率、token 成本。
2. Tool 层：调用次数、成功率、执行时长、超时率。

Trace 结构建议绑定 session_id + turn_id + step_id，以便还原完整 trajectory。

Benchmark

有了 Trace 和可恢复执行能力后，可以把线上真实任务沉淀为 benchmark 回放集。

flowchart LR    TR[(Trace Store)]    SEL[Scenario Selector]    REP[Replay Runner]    EVAL[Scoring/Eval]    RPT[Model Report]    TR --> SEL --> REP --> EVAL --> RPT

评测重点不只看“是否成功”，还要看：

1. 端到端时延与成本。
2. 工具调用效率和失败恢复能力。
3. 不同模型在同一任务族上的稳定性差异。

总结一下Agent的发展历程和架构演进，聊聊几个抽象概念，最后说说我觉得未来Agent架构的一个可能方向。

Chatbot

最开始出现的是Chatbot应用。Chatbot 是一个状态系统。每轮请求执行四个步骤：读取上下文、构造 prompt、调用模型、写回状态。系统设计的重点不在模型接口，而在状态组织方式。

会话状态建议分为两层：

• 显示层（Display Layer）：保存原始事件流，面向 UI 展示、回放与审计。
• 业务层（Business Layer）：保存推理就绪上下文，面向 prompt 构造与成本控制。

该分层支持一条工程约束：业务层允许静默压缩与摘要，显示层保持完整历史，不做语义改写。

1) 分层职责图

flowchart LR    UI[Display Layer<br/>raw events / replay / audit]    BL[Business Layer<br/>processed context / prompt-ready]    UI -. isolated goals .- BL

这张图定义职责边界。两层的输入输出、服务对象、演化策略均不同。混用单层存储会产生三类问题：

1. prompt 长度随轮次线性增长，推理成本和时延同步上升。
2. 展示格式、系统指令、工具中间消息进入模型输入，降低上下文信噪比。
3. 压缩策略直接作用于用户可见历史，破坏回放一致性与审计可读性。

2) 写路径图

flowchart LR    U[User] --> API[Chat API] --> SVC[Conversation Service]    SVC --> CP[Context Processor]    CP --> LLM[LLM Inference]    LLM --> SVC    SVC --> DDB[(Display History Store)]    SVC --> BDB[(Business Context Store)]

写路径采用双写：同一轮请求同时更新显示层与业务层。

• Display History Store 记录 raw user/assistant events。
• Business Context Store 记录 processed context。

Context Processor 负责从“展示消息”生成“推理上下文”，常见操作为：

• truncate（窗口裁剪）
• compress（信息压缩）
• summarize（阶段摘要）
• metadata filtering（移除展示噪声字段）

3) 推理读路径图

flowchart LR    SVC[Conversation Service] -->|load prompt context| BDB[(Business Context Store)]    BDB --> SVC    SVC --> LLM[LLM Inference]

推理路径只读取业务层。该约束保证三点：

• 输入长度可预测。
• 关键语义可延续。
• prompt 结构可标准化。

4) 显示回放图

flowchart LR    UI[Chat UI] --> API[Chat API]    API --> DDB[(Display History Store)]    DDB --> API --> UI

展示路径只读取显示层。UI 获取的是原始事件轨迹，不依赖推理优化后的上下文快照。该路径为回放、排障、审计提供稳定数据源。

5) Context Engineering

在 Chatbot 阶段，Context Engineering 关注两个问题：

1. 上下文压缩：在 token budget 固定的前提下，保留任务相关信息。
2. 用户记忆 / 偏好：在跨轮次交互中维持行为一致性。

这一阶段的重点是定义问题边界和评估标准，不在于引入复杂机制。

结论

• Chatbot 架构已经形成显示层与业务层的初步分层：前者负责事件回放与审计，后者负责推理上下文组织。
• Chatbot 阶段已经出现上下文管理问题：上下文压缩与用户记忆/偏好管理成为后续架构演进的核心输入。

Agent in VM

第二种形态是 Agent 与用户共处同一台 VM。与 Chatbot 阶段相比，这一形态把“对话系统”扩展为“执行系统”：Agent 不再只组织上下文，还直接操作 Shell、文件系统、浏览器和桌面环境。

这个形态的核心变化是：

• 执行环境从 API 工具调用，转为真实操作系统环境。
• 状态边界从会话消息，扩展为 VM 全状态（文件、进程、浏览器、环境变量）。
• 用户可通过 VNC/SSH 与 Agent 并行操作同一环境。

1) 形态定义与架构边界

flowchart LR    U[User] -->|VNC/SSH| VM[User VM]    WEB[Web Chat] --> AG[Agent Process in VM]    subgraph VM[User VM]        AG        SH[Shell]        FS[(Filesystem)]        BR[Browser]        DE[Desktop]    end    AG --> SH    AG --> FS    AG --> BR    DE --> SH    DE --> BR

该架构的边界很直接：Agent 和用户共享同一运行时。系统一致性高，系统隔离弱。

2) 运行时交互流

sequenceDiagram    participant User as User(VNC/SSH)    participant Web as Web Chat    participant Agent as Agent(in VM)    participant LLM as LLM API    participant Shell as Shell    participant FS as Filesystem    participant Browser as Browser    User->>Shell: direct command    Shell->>FS: read/write    Web->>Agent: task request    Agent->>LLM: planning + tool call    LLM-->>Agent: action    Agent->>Shell: execute command    Shell->>FS: read/write    Agent->>Browser: open/click/type    Agent-->>Web: result    User->>FS: inspect changes immediately

这一形态的优势在于“可观察 + 可干预”：用户可以实时看到 Agent 的执行结果，也可以随时接管。

3) 状态持久化：从会话状态到 VM 快照

Chatbot 阶段主要持久化消息与上下文。Agent-in-VM 阶段需要持久化完整环境状态，通常依赖 VM Snapshot。

sequenceDiagram    participant P as Platform    participant VM as VM    participant S as Snapshot Storage    P->>VM: pause    VM-->>P: frozen    P->>S: save memory snapshot    P->>S: save disk snapshot    P->>VM: terminate    P->>S: load snapshots    S-->>P: memory + disk    P->>VM: restore    VM-->>P: resumed

快照带来的工程收益是“连续执行上下文”：文件、进程、浏览器状态可以跨会话恢复。典型场景是开发服务器和调试现场的延续。

4) 主要约束与风险

这个形态在通用性上很强，但成本与安全边界会前置成为架构问题：

• 成本约束：每用户独占 VM，空闲成本高，扩展效率低于共享计算架构。
• 调度约束：VM 启停与快照恢复时延高于无状态容器调度。
• 安全约束：Agent 进程与用户共域，密钥管理、权限边界、篡改防护更复杂。
• 持久化风险：恶意进程或敏感凭证可能通过快照跨会话保留。

结论

• Agent in VM 形态把系统能力从“对话组织”推进到“环境执行”，获得了强交互、强观察、强持久化能力。
• 这一形态同时引入了新的主问题：多租户安全边界、VM 成本模型与快照生命周期治理。

Agentic LLM API

第三种形态可以定义为 Agentic LLM API：交互入口仍是 Chatbot，但执行能力已经升级为 Agent，并由模型 API 厂商托管执行环境。与 Agent in VM 的区别在于，用户不直接进入执行环境；与第一阶段 Chatbot 的区别在于，系统不仅维护消息状态，还维护可执行环境状态。

这一形态的目标是把“对话编排”与“环境执行”做成一条端到端链路：

• 对用户暴露稳定的聊天接口。
• 对系统内部暴露可控的工具与执行环境。
• 在 token 成本、延迟与可观察性之间取得工程平衡。

1) 形态定义与系统边界

flowchart LR    U[User]    CHAT[Chat Interface]    AGENT[Agent Orchestrator]    MEM[(Session & Memory Store)]    CE[Code Execution Runtime]    TOOLS[Internal/External Tools]    U --> CHAT --> AGENT    AGENT <--> MEM    AGENT --> CE    CE --> TOOLS    TOOLS --> CE --> AGENT --> CHAT --> U

边界定义：

• Control Plane：会话、记忆、策略、路由。
• Execution Plane：代码执行容器或沙箱运行时。
• Tool Plane：数据库、检索、业务 API、浏览器等外部能力。

2) 执行流：从直接工具调用到程序化工具调用

Agentic Chatbot 的关键变化，是把多步工具调用下沉到执行环境中，以减少模型轮次开销。典型实现是 Programmatic Tool Calling（PTC）模式：模型生成可执行代码，在运行时中循环调用工具、过滤中间结果，再回传高价值输出。

sequenceDiagram    participant U as User    participant A as Agent Orchestrator    participant L as LLM    participant R as Execution Runtime    participant T as Tool/API    U->>A: task    A->>L: planning prompt    L-->>A: code-oriented action    A->>R: run code block    loop in runtime        R->>T: call tool        T-->>R: raw result        R->>R: filter/aggregate/branch    end    R-->>A: compact result    A->>L: final reasoning    L-->>A: answer    A-->>U: response

该流程的工程意义是：中间数据处理不进入主上下文窗口，模型只消费压缩后的关键结果。

3) 状态模型：消息状态 + 环境状态 + 运行状态

Chatbot 阶段主要管理消息状态；Agentic Chatbot 需要三类状态并存。

flowchart LR    M[(Message State)]    E[(Environment State)]    R[(Run State)]    M --> C[Context Builder]    E --> C    R --> C    C --> P[Prompt/Action Decision]

• Message State：对话历史、摘要、用户偏好。
• Environment State：容器 ID、文件系统变更、工具上下文。
• Run State：任务阶段、工具调用链、重试与超时信息。

系统可恢复性依赖于这三类状态的一致性，而不是单一会话历史。

4) 主要约束

Agentic LLM API 的主要工程约束集中在五点：

• 安全约束：执行环境必须隔离，工具调用需要 caller 权限边界与 allowlist。
• 时效约束：执行容器存在 TTL，跨步调用需要超时恢复和幂等设计。
• 观测约束：需要保留 action trace、tool I/O、版本化 prompt 以支持回放。
• 成本约束：执行时长、容器复用、上下文压缩共同决定单位任务成本。
• 供应商锁定约束：执行环境上下文（container state、intermediate artifacts、tool-call runtime state）主要保存在 API 厂商侧，迁移到其他模型供应商时，状态可移植性与行为一致性难以保证。

关于供应商锁定，这一形态有两个具体后果：

1. 状态不可携带：迁移供应商时，通常只能带走消息历史，难以带走运行时上下文。
2. 行为不可等价：即使接口相似，不同厂商在执行容器、超时策略、工具调用协议上的差异会导致任务行为漂移。

锁定面的核心不在 API schema，而在运行时语义：

flowchart TB    subgraph HighPortability[High Portability]        M[Message History<br/>input/output transcripts]    end    subgraph MediumPortability[Medium Portability]        T[Tool Contracts<br/>name/schema/params]    end    subgraph LowPortability[Low Portability]        R[Runtime State<br/>container/session/artifacts]        S[Execution Semantics<br/>timeout/retry/caller policy]    end    M --> T --> R    T --> S

可迁移性通常呈分层下降：消息层 > 工具协议层 > 运行时状态层。

这里和很多厂商（OpenAI & Gemini）在API中隐藏自己的thinking过程不同，环境状态的丢失使得迁移供应商是不可能的，而非之前的“丢失一些中间思考”。

结论

这对于模型厂商获取数据和用户锁定都有积极意义，也为第一方应用提供了非常强大的能力，但对于开发者来说，几乎不可能选择这类方案，其供应商锁定和不透明问题带来的风险太高了。

Next: Agent Mounts Environment

Agent in VM 形态虽然提供了强交互能力，但存在两个核心问题：一是每用户独占 VM 的成本模式导致空闲成本高；二是 Agent 与用户共域，API Keys 与内部逻辑暴露在 VM 环境，难以安全整合私有服务。

Agent Mounts Environment 将 Agent 与执行环境解耦：Agent 仍运行在平台侧（可访问私有服务、密钥隔离），但将执行环境降级为一个”挂载点”。VM 内仅运行轻量级 Executor，负责接收 Agent 的指令（Shell 命令、文件操作、浏览器控制）并反馈结果。

flowchart LR    subgraph Platform["Platform (Secure Zone)"]        Agent["Agent Service"]        PrivateAPI["Private Services"]    end    subgraph VM["User VM (Mounted Environment)"]        Executor["Executor"]        Shell["Shell"]        FS["Filesystem"]    end    Agent <-->|"SSH/CDP"| Executor    Agent <-->|"API"| PrivateAPI    Executor --> Shell    Executor --> FS

好处

1. 安全隔离：Agent 与用户环境物理分离，密钥与内部逻辑不暴露在 VM 中。Agent 可安全访问私有数据库、内部 API，而无需在 VM 中存储凭证。

2. 成本优化：Agent 进程不与用户 VM 绑定，可跨多用户复用（或采用共享计算资源池）。VM 仅作为执行容器，不需要持续为每用户保留计算资源。

3. 权限边界清晰：Executor 可施加细粒度权限控制：允许的工具集、可访问的文件路径、外部 API 调用权限均由平台策略决定，用户无法绕过。

4. 与 Agentic LLM API 兼容：该架构天然支持多模型厂商，Agent 逻辑独立于执行环境实现，迁移或切换 LLM 供应商时，运行时语义保持一致。

挑战

1. 通信协议复杂性：Agent 需要通过 SSH、SFTP、CDP Over SSH Tunnel 等多种协议与 VM 通信。每种协议的超时、重试、错误恢复策略都需要精心设计。协议层的不稳定会导致任务中断或重复执行。

2. 状态一致性困难：Agent 侧的任务状态与 VM 侧的执行状态可能不一致（如网络分区、超时导致的半成功操作）。需要设计操作幂等性、事务语义与恢复协议来保证最终一致性。

3. VM 快照与 Git 同步：若采用 VM 快照持久化完整运行时状态，需要在恢复后重新同步 Git 状态，否则磁盘内容与 Remote 不一致。这引入了额外的状态管理层。

结论

Agent Mounts Environment 是 Agent in VM 与 Agentic LLM API 之间的中间态：保留了本地执行环境的完整可观察性和持久状态能力，同时恢复了平台侧的安全边界与成本效率。代价是需要投入工程力量处理分布式系统的一致性问题。

Bonus: Durable Execution

Agentic Loop 中的执行容易失败：网络中断、超时、工具错误、模型幻觉都可能中断任务。要支持重试与恢复，需要把任务状态分层管理，而不是盲目地快照整个 VM 或重新执行任务。

关键是认识到不同类型的状态有不同的恢复语义：

1) 上下文（Context）

定义：LLM 模型推理所需的信息，包括prompt、当前目标、已执行步骤。

恢复策略：上下文应完全可重建，无需从快照恢复。重试时重新加载上一步的结果，让模型基于完整的执行历史做出新的决策。

为什么：即使模型上一次的决策有误，完整的history 能让它在第二次重试中做出不同的选择。

sequenceDiagram    participant A as Agent    participant M as Message Store    participant L as LLM    A->>M: Load history + last result    M-->>A: [step1, step2, step3: failed]    A->>L: Continue with full context    L-->>A: New action based on failure

2) 消息状态（Message State）

定义：对话历史、用户请求、AI 响应。

恢复策略：消息状态应仅追加（append-only），支持版本化重试。一次重试对应一条新分支，记录”第一次尝试失败”与”第二次重试成功”的完整轨迹。

存储方案：

flowchart LR    Root["Message 1: user request"]    Exec1["Message 2a: Agent planning (attempt 1)"]    Exec2["Message 2b: Agent planning (attempt 2)"]    Result1["Message 3a: Tool result FAILED"]    Result2["Message 3b: Tool result OK"]    Root --> Exec1    Root --> Exec2    Exec1 --> Result1    Exec2 --> Result2

通过消息树（而非单线性链表）记录重试分支，支持审计与故障分析。

3) 文件系统状态（Filesystem State）

定义：VM 或容器内的文件、目录、权限。

恢复策略：文件系统状态通过 git commit 或 VM 快照持久化。重试时的关键决策是：是否需要恢复到操作前的状态还是基于当前状态重新操作。

两种模式：

模式 A：Ephemeral + Rollback（容器/Sandbox 方案）

• 每次工具调用在隔离容器内执行
• 失败时容器销毁，文件系统回滚
• 下一次重试从 Git Checkout 状态开始

sequenceDiagram    participant A as Agent    participant C1 as Container (attempt 1)    participant C2 as Container (attempt 2)    participant FS as Shared FS (Git managed)    FS-->>C1: mount current HEAD    A->>C1: npm install    C1->>FS: write XXX (not committed)    Note over C1: Fails, container destroyed    FS-->>C2: mount current HEAD (clean state)    A->>C2: npm install (retry)    C2->>FS: write YYY

优点：简单、可预测。缺点：无法利用前一次的中间成果（如部分安装的依赖）。

模式 B：Persistent VM + Checkpoint（VM 快照方案）

• 使用 Firecracker Snapshot 保存完整运行时状态
• 失败时从快照恢复，保留内存中的进程、缓存
• 需要额外的 checkpoint 机制记录”哪些文件修改可以撤销”

sequenceDiagram    participant A as Agent    participant VM as VM    participant S as Snapshot    A->>VM: Save checkpoint (git state + memory snapshot)    S-->>VM: checkpoint_id_v1    A->>VM: npm install    VM->>VM: partial install (process in memory)    Note over VM: Fails    A->>S: Restore checkpoint_id_v1    S-->>VM: Memory + disk restored    A->>VM: npm install (retry, hot cache)

优点：快速恢复、热启动。缺点：快照本身占用存储空间，恢复涉及内存一致性问题。

4) 外部资源状态（External Resource State）

定义：API 调用、数据库事务、第三方服务的执行结果。

恢复策略：外部资源操作的可恢复性取决于操作是否幂等。

分类：

实现模式：Idempotency Key

sequenceDiagram    participant A as Agent    participant API as External API    participant Cache as Idempotency Cache    A->>Cache: Lookup idempotency_key = "task_step_3"    Cache-->>A: Not found    A->>API: POST /charge (idempotency_key: "task_step_3", amount: 100)    API->>Cache: Save result (charged: true)    Cache-->>API: OK    API-->>A: success    Note over A: Network timeout, retry    A->>Cache: Lookup idempotency_key = "task_step_3"    Cache-->>A: Found (charged: true)    A->>A: Return cached result without re-charging

系统需要为每个工具调用分配全局唯一的 idempotency_key，存储每次调用的结果。重试时先查询缓存，避免重复操作。

综合设计

完整的 Durable Execution 系统需要四层状态管理：

flowchart TB    Context["Context Layer<br/>(Stateless, computed from Message State)"]    Message["Message State<br/>(Append-only, versioned history)"]    FileSystem["Filesystem State<br/>(Git checkpoint or VM snapshot)"]    External["External State<br/>(Idempotency cache + verification)"]    Message --> Context    Message --> FileSystem    Message --> External    Context -.-> Recovery["Recovery via Context + Message Replay"]

在故障发生时，恢复顺序为：

1. 检查外部资源状态（是否已执行）→ 如有缓存结果则直接返回
2. 检查文件系统状态（Snapshot 或 Git HEAD）→ 重建执行环境
3. 加载消息历史 → 重建 LLM 上下文
4. 重新执行失败的步骤

结论

Durable Execution 的核心是认识到：系统的可恢复性不源于单一快照，而源于分层的状态管理与操作的幂等性设计。不同类型的状态有不同的持久化需求与恢复成本，混为一谈会导致过度的快照成本或无法恢复的局面。

前言： 聊到了 AI Native 组织的形态，记录几个当下的直觉。

1. 组织即灵魂

同样是基于 LLM，OpenAI 做出来的产品像大众工具，DeepMind 做出来的像科学仪器。产品不再是工业流水线上的标准化件，而是组织认知的直接投射。

直觉： 不同的组织“性格”，决定了 AI 产品的“灵魂”。

2. 网络式共振

在 AI 时代，传统的层级式指令管理正在失效。因为创新的源头往往在一线研发的探索中涌现。

直觉： 未来的组织更像是一个“超级兴趣小组”。大家因为一个远期目标聚在一起，通过高频的网络式协作（你读一篇 Paper，我试一个 Demo），把个体的认知拉齐、拉高。最终那个超越时代的产品，是在整个团队高认知水位上自然浮现的结果。

3. 商业化是真实世界的 RLHF

商业化不仅仅是为了生存，它更是一个高价值信号过滤器。

免费用户的反馈往往是“好玩”（Novelty），付费用户的反馈往往是“没用”或“不准”（Utility）。只有那些愿意付费的用户反馈，才是最真实的 Reward Model，迫使团队直面真实世界的复杂性（Corner Cases），把“玩具”打磨成“工具”。

直觉： 商业化把“用户反馈”转化为了高质量的“训练数据”。

注脚：组织环境即 RL Environment

如果我们把组织看作一个强化学习（RL）的环境：

• Agent： 每一个团队成员。
• Action： 每天的探索、决策、代码、讨论。
• Reward： 组织鼓励什么？是快速试错给正反馈，还是按部就班给正反馈？
• State： 整个团队当前的认知水位、技术栈、氛围。

如果不精心设计这个 Environment 的 Reward Function，你就得不到那种自驱、涌现式的创新。

这篇文章分享我在 AI 辅助开发中保持项目一致性的一些实践。

核心洞察：瓶颈变了

传统软件开发的瓶颈是编码。设计完成后，大量时间花在实现上。

flowchart LR    A[设计] --> B[编码]    B --> C[Review]    C --> D[修改]    D --> B

AI 辅助开发打破了这个瓶颈。编码变得很快，但新的问题出现了：

flowchart LR    A[设计] --> B[AI编码]    B --> C[代码量暴增]    C --> D[理解跟不上]    D --> E[架构腐化]    E --> F[更多patch]    F --> E

编码不再是瓶颈，理解和架构才是。

方法论：控制点上移

要打破这个负循环，关键是把控制点从”代码”上移到”架构”。

flowchart TB    subgraph Control[控制层]        A[Spec文档]        B[Owner审阅]    end    subgraph Constraint[约束层]        C[agents.md]        D[类型系统]        E[项目规则]    end    subgraph Execution[执行层]        F[AI生成代码]        G[Prototype]        H[生产代码]    end    A --> B    B --> C    B --> D    B --> E    C --> F    D --> F    E --> F    F --> G    G -->|验证通过| H    G -->|需要调整| A

1. Spec 文档驱动

把脑海里的架构变成和 AI 讨论的 spec 文档：

• 概要设计：系统边界、模块划分、核心流程
• 架构图/流程图：用 mermaid 或手绘，让 AI 理解上下文
• DDD 思路：bounded context、聚合、领域语言

不需要细到接口签名。模块边界清晰，AI 就不会跨模块乱搞。

flowchart LR    A[脑海中的架构] --> B[Spec文档]    B --> C[与AI讨论]    C --> D[AI生成代码]    D --> E[代码符合架构]

2. 自底向上构建

很多人习惯自顶向下：先设计接口，再实现细节。但在 AI 辅助开发中，我发现自底向上更有效：

• 先做配置：配置是系统的”骨架”，定下来后 AI 生成的代码就有约束
• 先定类型：类型系统是天然的约束，让 AI 在框里活动
• 从不易变的开始：基础设施、工具函数、配置管理

这样做的好处：

• 更容易获得良好的抽象
• 更容易进行测试覆盖
• AI 生成的代码有锚点，不会飘

3. 约束前置

与其事后 review 代码，不如事前约束 AI：

flowchart LR    subgraph Constraints[约束]        A[agents.md]        B[pyright]        C[ESLint]        D[项目规则]    end    E[AI] --> Constraints    Constraints --> F[符合规范的代码]

• agents.md / AGENTS.md：写清楚项目的架构、约定、禁忌
• 类型系统：pyright、TypeScript，静态分析是最好的约束
• 项目规则：命名规范、目录结构、commit 格式

AI 读了这些约束，生成的代码一致性会好很多。

4. 早期重构

重构应该在最早的时候进行，而不是等代码堆积成山：

• 代码量小，重构成本低
• 最容易利用 AI 的生成能力
• 最不容易受幻觉影响

等到项目复杂了再重构，AI 会产生更多幻觉，因为它无法完全理解所有上下文。

5. 快速验证，慎重生产

flowchart LR    A[想法] --> B[Prototype]    B --> C{验证}    C -->|通过| D[生产化]    C -->|失败| E[调整想法]    E --> A    D --> F[留重构空间]

• 尽快 prototype：用 AI 快速验证想法
• 慎重生产：验证通过后再决定是否生产化
• 留重构空间：不要过早固化，保持灵活性

正反馈循环

好的实践会形成正反馈：

flowchart LR    A[好架构] --> B[AI生成正确代码]    B --> C[省时间]    C --> D[优化架构]    D --> A

差的实践会形成负反馈（要避免）：

flowchart LR    A[烂架构] --> B[代码到处patch]    B --> C[越来越乱]    C --> D[没时间重构]    D --> A

团队协作

在多人协作中，一致性更重要：

• 项目有 Owner：Owner 审阅 spec，保持架构一致性
• Review spec，不只是 review 代码：比传统 code review 更高效
• AI review 辅助：让 AI 检查代码是否符合 spec

flowchart TB    A[Owner] -->|审阅| B[Spec]    B -->|指导| C[开发者1]    B -->|指导| D[开发者2]    C --> E[代码]    D --> E    E -->|AI Review| F{符合Spec}    F -->|是| G[合并]    F -->|否| H[修改]    H --> E

工程师角色转变

AI 辅助开发正在改变工程师的角色：

工程师的核心价值变成了：

• 架构抽象能力：基于当前理解设计合理的架构
• 业务理解：对当前情况和未来进行抉择
• 质量把控：确保 AI 生成的代码符合预期

这本就是架构师的任务。有了 AI 辅助编码，我们可以有更多时间放在设计更容易维护的架构上，反过来又方便了 AI 编码，实现正反馈。

总结

AI 辅助开发的核心是人机协作：

• 人负责：架构决策、业务理解、质量把控
• AI 负责：快速实现、重复劳动、代码生成

保持项目一致性的关键：

1. 控制点上移：从代码到 spec
2. 约束前置：用规则和工具约束 AI
3. 早期重构：趁代码量小的时候
4. 快速验证：prototype 快，生产慢
5. 正反馈循环：好架构 → 好代码 → 更好架构

AI 不会取代工程师，但会取代不会用 AI 的工程师。掌握 AI 辅助开发的方法论，才能在这个时代保持竞争力。

最近和 AI 讨论了一个有意思的话题:在 AI Native 时代,Agent 产品存在一种独特的”软件腐化”——它不是传统意义上的代码腐化,而是发生在智能层面的劣化。

传统软件腐化讲的是代码层面:重复、耦合、复杂度上升。Agent 腐化是另一种东西——系统逐渐变得更蠢、更僵化、更难迭代,而且这种劣化在常规指标上往往不可见。

一个典型场景

产品经理说:”用户一提到数据库,就推荐我们的数据库产品,这样能提升功能渗透率。”

技术团队加上了这条规则。渗透率确实上去了。

然后产品经理又说:”用户提到性能问题,就推荐我们的监控方案。”

又加了一条规则。

一年后,Agent 里有 50 条这样的规则。产品经理拿着一个”纯净版”Agent 对比说:”为什么我们的 Agent 比这个蠢这么多?技术团队要提高智能水平。”

技术团队:”……”

腐化的几种形态

1. 规则堆积 (Rule Accumulation)

每条规则单独看都合理,加起来就是:

• Prompt 越来越长,优先级冲突难以调试
• 模型的自主判断空间被不断压缩
• 改一个地方,另一个地方出 bug

最讽刺的是:你花钱买了 GPT-4 的智能,然后用 if-else 覆盖了它的判断。

2. 上下文膨胀 (Context Bloat)

为了让 Agent “更懂用户”,不断往 context 里塞东西:用户历史、产品信息、各种 metadata。

结果:上下文窗口被低价值信息填满,真正重要的信号被稀释,模型”注意力”被分散。

3. 工具蔓延 (Tool Sprawl)

一开始 5 个工具,边界清晰。后来 50 个工具,功能重叠,Agent 自己都不知道该调哪个。

工具选择错误率上升,维护成本爆炸。

4. 评估漂移 (Evaluation Drift)

早期评估 Agent 真正的智能水平。后来评估变成”有没有触发这个规则””有没有推荐这个产品”。

指标和智能脱钩,团队在优化错误的东西,智能下降但指标上升,问题被掩盖。

5. 人设分裂 (Persona Fragmentation)

产品说要”专业可靠”,运营说要”活泼有趣能带货”,客服说要”严谨不能出错”。

同一个 Agent 被拉向不同方向,最后人格分裂,用户感知”这个 AI 很奇怪”。

温水煮青蛙

这种腐化最危险的地方在于:它是渐进的。

每条规则单独看都”有效”——短期数据确实在涨:

• 功能渗透率:↑
• 转化率:持平或略升
• 结论:”有效,继续加”

但债务在暗处累积。用户体验不是一下子变差,是慢慢变得”不那么聪明”。用户说不出哪里不对,但就是不想用了。留存慢慢掉,归因不到任何单一功能。

等你意识到问题的时候,系统已经改不动了。

根源在哪

1. 短期指标驱动:每个决策都优化局部指标,没人为 Agent 整体智能负责。

2. 技术缺乏话语权:技术知道加规则有问题,但产品数据说”有效”,技术说了不算。

3. 因果被切断:产品加规则拿到渗透率功劳,智能下降技术背锅。制造债务的人不承担后果。

4. 没有”智能债务”概念:传统技术债有行业共识,Agent 智能债没有度量、没有意识。

如何对抗

借鉴软件工程的经验

在传统软件工程中,架构师的职责是保持一致性、做对的抽象、防止腐化,辅以及时重构。

Agent 产品需要类似的角色:智能架构师。

智能架构师的职责

1. 定义 Agent 的”宪法”:核心行为准则,所有规则都要服从它。

2. 守护 Prompt 的一致性:不是谁都能往里加东西。

3. 把控工具边界:新工具要审核,工具粒度要合理。

4. 拥有否决权:产品要加破坏智能的规则,可以说不。

5. 维护纯净 baseline:始终有一个无业务污染的版本作为参照。

建立”智能债务”指标

• 硬编码规则数量
• Prompt 复杂度
• 模型自主决策比例 vs 规则覆盖比例
• 纯净版 vs 当前版的智能评分差距

让债务可见,而不是只看功能渗透率。

流程机制

• 偿还计划:每条规则要有下线条件和时间,不是加了就永远在。
• 定期清理:每季度 review 所有硬编码逻辑。
• 决策权和后果绑定:谁加的规则,谁对智能指标负责。

组织架构

1
2
3

Product (What/Why) ←→ Agent Architect (守护智能) ←→ Engineering (How)
                              ↓
                      Evaluation/QA (度量智能)

关键:Agent Architect 要独立,有独立 KPI,可以 challenge 产品和工程双方。

AI Native 时代的特殊性

这里有一个更深的问题:在 Agent 产品中,技术团队的角色发生了变化。

传统软件:PM 定义 What/Why,工程定义 How。

但 Agent 不一样:

• 能力边界不清晰:能不能做到、做到什么程度,取决于技术实现。
• How 决定了 What 的可能性:用什么模型、怎么做 tool calling、怎么处理上下文——这些不是实现细节,是产品形态的根本约束。
• 体验是涌现的:Agent 的体验取决于它”怎么思考”,这完全是技术层面的事。

所以,Agent 产品中的技术团队,不只是 How,而是要参与 Why:

• Why this approach works
• What’s actually possible
• Where the real value is

这不是越界,是 Agent 产品的本质要求。

写在最后

Google DORA 2025 报告有一句话说得很好:

AI doesn’t fix a team; it amplifies what’s already there.

Agent 腐化本质上是技术债 + 组织债的结合体。每个人都在优化自己的局部指标,没人看整体——这和 LLM “优先保证局部功能正确,而不是全局架构一致性”是同一个问题。

只解决技术层面不够,需要组织层面的改变。

如果你也在做 Agent 产品,希望这篇文章能让你在下次加规则之前,多问一句:这条规则的智能债务是什么?谁来偿还?

In this post, we explore how the Environment abstraction in pai-agent-sdk implements dependency inversion, why this design embeds OS-centric assumptions, and how it shapes everything from tool implementation to context engineering.

The Instinctive Path

Watch any developer build their first agent. The conversation typically goes:

1. “I need my agent to do things”
2. “Doing things means reading/writing files and running commands”
3. “Therefore, I need FileOperator and Shell”

This mental model is so pervasive that it feels like the only way. But it’s actually a specific architectural choice that assumes agents operate in OS-like environments.

Dependency Inversion: The Code Level

From a pure code perspective, pai-agent-sdk implements classic dependency inversion:

graph TB    subgraph "High-Level Modules"        Agent[Agent]        Toolset[Toolset]    end    subgraph "Abstractions"        Env[Environment ABC]        FO[FileOperator Protocol]        SH[Shell Protocol]    end    subgraph "Low-Level Implementations"        Local[LocalEnvironment]        Docker[DockerEnvironment]    end    Agent --> Env    Toolset --> Env    Env --> FO    Env --> SH    Local -.->|implements| Env    Docker -.->|implements| Env

Tools don’t know whether they’re running locally or in a container:

1
2
3
4
5
6
7
8
9
10
11
12
13

class ViewTool(BaseTool):
    async def call(self, ctx: RunContext[AgentContext], file_path: str) -> str:
        # Uses abstraction, not concrete implementation
        file_operator = ctx.deps.file_operator
        content = await file_operator.read_file(file_path)
        return content

class ShellTool(BaseTool):
    async def call(self, ctx: RunContext[AgentContext], command: str) -> ShellResult:
        # Same pattern - abstract Shell interface
        shell = ctx.deps.shell
        exit_code, stdout, stderr = await shell.execute(command)
        return ShellResult(stdout=stdout, stderr=stderr, return_code=exit_code)

This is textbook dependency inversion:

• High-level modules (Agent, Tools) depend on abstractions
• Low-level modules (LocalEnvironment, DockerEnvironment) implement abstractions
• Abstractions don’t depend on details

The Conceptual Leakage

But here’s the subtle issue: the shape of our abstractions is molded by OS concepts.

Even when we successfully invert dependencies at the code level, we’re still thinking in terms of “files”, “directories”, “commands”, and “environment variables”. The abstraction has absorbed the OS worldview.

This isn’t necessarily wrong - it’s a pragmatic choice. But it limits our imagination when considering alternative environments.

The Ripple Effect: Tool Availability

The OS-centric design manifests in how tools check their availability:

1
2
3
4
5
6

class ShellTool(BaseTool):
    def is_available(self, ctx: RunContext[AgentContext]) -> bool:
        # Tool becomes unavailable if shell isn't configured
        if ctx.deps.shell is None:
            return False
        return True

This creates an implicit contract: environments without shell capability simply can’t use shell-based tools. The tool system gracefully degrades, but the degradation path is defined by OS capabilities.

Context Engineering: Environment Shapes the Prompt

Perhaps the most profound impact is on context engineering. The environment doesn’t just provide tools - it shapes how we communicate with the model.

1
2
3
4
5
6
7
8
9
10
11

# From filters/environment_instructions.py
async def inject_environment_instructions(
    ctx: RunContext[Any],
    message_history: list[ModelMessage],
) -> list[ModelMessage]:
    # Get environment-specific instructions
    instructions = await env.get_context_instructions()

    # Inject into the conversation
    env_part = UserPromptPart(content=instructions)
    last_request.parts = [*last_request.parts, env_part]

What does get_context_instructions() typically return? Something like:

1
2
3
4
5
6
7
8
9
10

<environment-context>
  <file-system>
    <default-directory>/home/user/project</default-directory>
    <allowed-paths>/home/user/project, /tmp/workspace</allowed-paths>
  </file-system>
  <shell-execution>
    <default-timeout>30s</default-timeout>
    <working-directory>/home/user/project</working-directory>
  </shell-execution>
</environment-context>

The model receives instructions framed entirely in OS terminology. We’re not just providing tools - we’re teaching the model to think in terms of paths, directories, and shell commands.

The Three Layers of Environment Influence

graph LR    subgraph "1. Tool Implementation"        TI[Tools use FileOperator/Shell abstractions]    end    subgraph "2. Tool Availability"        TA[Tools check environment capabilities]    end    subgraph "3. Context Engineering"        CE[Prompts include environment instructions]    end    Env[Environment] --> TI    Env --> TA    Env --> CE    TI --> Agent    TA --> Agent    CE --> Agent

1. Tool Implementation: Tools operate through environment abstractions
2. Tool Availability: Tools self-disable based on environment capabilities
3. Context Engineering: System prompts are shaped by environment context

All three layers reinforce the OS-as-environment paradigm.

Alternative Perspectives

What if we didn’t assume OS as the default? Consider alternative environment types:

Each would require different:

• Tool implementations
• Availability checks
• Context instructions

Takeaways

1. Dependency inversion at code level: Achieved through Environment/FileOperator/Shell abstractions

2. Conceptual dependency on OS: The abstractions themselves reflect OS-centric thinking

3. Three-layer influence: Environment shapes tool implementation, availability, and context engineering

The next time you build an agent and instinctively reach for file system tools, pause and ask: “Is this the right environment for my agent?” The answer might still be yes - but it’s worth asking the question.

如果在客户端实现，则至少需要编写代码-执行代码两个轮次，甚至更多

下面这张图很好的解释了整个工作流程：

以上基本上是大部分自媒体/公众号/营销号对于它的理解，以下我提供一些不一样的看法，可能不一定成熟。

有状态API应该包含环境状态，而不是消息状态

有状态API的起始是OpenAI的Responses API，在我看来其主要目的有二：

1. 允许客户端可以在发起任务之后异步获取结果，以减少服务器压力
2. 更好地在隐藏推理细节的同时，提供连贯推理的服务

但实际上，Responses API只是在性能上稍好，大部分时候OpenAI只享受到其数据安全的部分，因为Responses API实际上无状态模式，而大部分时候，我是使用无状态模式进行交互：实时拉取流，保存thinking signature而非id，完整回填整个消息列表

PTC提供了一种带有环境状态的API，其编写、执行代码将对其服务端的对应环境造成影响，简单来说，过去我们让Agent改文件，所有文件状态的更新发生在我的本地，而Agent需要主动获取我本地的环境信息，这依赖于我，确切的说是我所使用的客户端，Claude Code、Codex CLI、Cline等等具体的工具实现，而PTC模式下，这些工具是在服务端沙盒实现的，没有实现者的bias、没有普适性要求、也没有那么多需要考虑的适配和安全问题。

端到端的数据积累

过去，模型公司收集到的用户使用数据只能通过消息，我们常说Cursor的价值在于积累了很多用户交互的真实数据，实际上指的就是环境数据和消息数据的结合。现在，PTC展示了一种模型厂直接端到端收集Agent数据的方式，通过一个已经跑通的、需要智能的场景，通过收集这方面的数据，或许能够切实地推进从ReAct到CodeAct的效率和智能提升。

Claude Code Agent SDK远远不够，PTC是Anthropic真正想要的东西。

那么，或许对bun的收购也顺理成章？

最近花了很多时间在研究各个模型之间的差别，同一个prompt下面，不同的厂商的模型所表现出的trajectory差别巨大。同时，随着年末大家的混战，我们惊喜的发现OpenAI、Anthropic、Google三足鼎立的局面似乎正在形成。当我们觉得GPT-5 Codex横扫四方时，Sonnet 4.5的出色表现让我感觉Anthropic并未落后，而Gemini 3 Pro非常惊喜地让我们看到一个经济、速度、性能都非常均衡的选择。

最近我在使用Claude Opus 4.5来进行Rust项目的编写（构建一个LLM网关来进行智能路由，等我完成后会有博客来介绍），明显感觉到与Sonnet 4.5相比，Opus更加谦逊且精准，就我而言，目前最佳的使用方式仍然是与AI讨论设计，输出技术架构和详细设计文档，然后在手动控制上下文长度的前提下（大部分时候是控制每次的任务大小），让Agent能够通过编写测试或其他方式验证实现的情况下，来完成代码编写工作。这一次更不一样的是，我选择了我没有那么熟悉，但是编译器和工具链都非常成熟的Rust语言，结果也非常令人满意。这表明，随着模型能力的提升，我们或许可以更加激进地探索和学习新的技术栈，而不必过于担心自己Debug的能力不足，相反，架构设计、可测试性、可维护性等软实力将变得更加重要。

Agentic Workflow

自Claude code横空出世，人们越来越倾向于采用一个简单的定义来描述Agent：大型语言模型在循环中自主使用工具来完成某个目标。

Agent Design Considerations

鉴于大模型的消息是无状态的，我们很容易拆分出LLM消息和工具实现两部分，MCP协议给了我们这样的一个example，通过streamable http或者本地stdio的方式，基于JSONRPC对工具定义进行分离。

接下来，我们很自然地思考，工具本身是否是有状态的？这就回到了Agent所针对的目标中。对于Coding Agent来说，其所处环境应是与人类程序员编程时使用的环境一样的开发环境，由以下组成：

• 代码和相关文件，或者说repo
• 运行时及运行依赖（编译和调试容器、其他已部署的服务、数据库、本地需要安装的调试库等等）

Agent本质上是在通过工具与上述两个环境进行交互，我们可以得出这样的描述：Agent通过不变的工具对环境进行改变，从而获得观察（observation），再指导其下一步动作。

这里及引出两个问题：

1. 工具一定是同步执行的吗？
2. 环境如何与Agent消息进行同步？

Async Tool Calling(and other jobs)

大多数API都允许Tool Response与User Message同时包含在一次请求中，只需要满足Tool Call和Tool Response在一次LLM请求和响应之间是成对出现的即可。因此，我们可以通过User Message，或包装Tool Response来提醒Agent哪些任务已经完成可以再次获取，或者将其他的系统异步任务添加到消息中。

另一种方式是让Agent直接管理异步任务，但由于自动压缩等上下文管理策略，我们需要确保Agent不会忘记已经启动的任务，并观测其结果

Sync Message and Environment

现在，我们需要将消息和环境进行绑定，如果我们想在任意时刻进行回滚重试，那么对于每一次工具调用都对应了一个环境快照，当这一依赖影响到数据库等不一定能回滚的资源时，我们就必须针对这类资源进行特别设计。

基于不同的开发模式，我们可以为用户提供不同程度的重试和回滚策略，从最基本的staging环境+prod环境，再到通过脚本自动创建本地环境模拟等等方式，一种思路是通过Infrastructure as code (IaC)+unit test的方式，使用脚本来确保开发环境的可重现，另一种思路则是在基础设施层就支持这一特性。而针对Agent消息，我们可以通过各类durable execution的基础设施来实现，搭配RPC Tool Calling，实现Agent消息的编排，具体可以参考：

• https://temporal.io/blog/what-is-durable-execution
• https://langchain-ai.github.io/langgraph/concepts/durable_execution/#using-tasks-in-nodes
• https://ai.pydantic.dev/durable_execution/overview/

User experience

用户体验通常是Agent系统设计忽略的一环，实际上工具调用可能长时间的无法流式输出，特别是编辑特别大的代码文件时，这会造成很大的用户体验问题。良好的用户体验常常可以让用户享受创作和解决问题的过程，而非仅仅交付物本身。我认为我们可以通过拆解工具调用的流式阶段，再通过一个非常轻量化的模型来进行流式输出，以提供流畅、易懂的用户体验。如果我们将异步任务视为一个消息系统，则可以考虑“Agent发起任务” - “Agent等待任务完成” - “任务已完成，等待Agent响应” - “Agent正在处理响应并进行下一步”的循环流程，而不是只能向用户展示“Agent调用工具中” - “Agent调用工具完成”的序列，用户也可以更清楚的了解系统的工作流程。

Context

Debug Agent应当由三个重要部分组成：用户上下文、程序上下文和自动化交互方案

用户上下文

当人们深入地使用Agent进行编程的时候，常常陷入debug困难的境地，表现为：

1. 很难描述自己遇到了什么问题，一种方案是进行截图或者录屏，然后交给一个有视觉、甚至可以处理视频（一般而言webp或者gif也可以）的agent来分析解决
2. 很难给出问题栈，比如点击某个按钮之后，http请求出错了，如何把问题提交给Agent进行解决

我希望通过“用户上下文”来描述此类场景，对应用户在使用产品的过程中遇到的bug和各种现象，也包括了运行时产生的各种上下文

程序上下文

程序上下文实际上是Agent来理解软件的工程，软件不仅仅是代码组成，还包括了对代码业务的理解和说明，类似所有Spec-drive开发，对于需求文档、技术选型、代码仓库的长短期记忆与规划和代码本身构成了程序上下文。Agent基于对程序上下文进行决策，理解和解决问题。

自动化交互方案

自动化交互方案是自动化测试在Agent上的实现，通过Agent进行交互来自动化地获取“用户上下文”。通过不同细粒度的自动化交互方案设计，如Browser use/Unit test/End-to-end test都对应了不同的用户上下文收集方式。

工作流程

发展阶段

我们分方面来看，程序上下文其实和Coding Agent基本一致，主要问题是保持软件开发过程中的文档和知识能够持续传承和更新；用户上下文与自动化交互相辅相成，是Debug Agent的重点。

程序上下文

第一阶段，引入最基本的记忆文件，类似AGENTS.md, CLAUDE.md，记录项目的重要信息

第二阶段，结构化记忆，使用或结合memory文件夹/RAG/抽取等方案，自动地存取用户对项目的一些要求、用户的偏好

第三阶段，规范驱动，结合用户体验一起，设计交互模式来推进产品需求、设计、功能开发和测试的全套程序上下文记忆存储

用户上下文与自动化交互

第一阶段，我们可以设计一系列工具（交互），让用户尽可能简单的反馈正确的用户上下文，同时集成一些简单的自动化交互来进行测试，比如截图、单元测试支持。目前看到良好的用户交互有：

• 截图标注
• gif/webp录屏

第二阶段，我们将设计一系列采集工具，对用户交互的运行时上下文进行自动化收集和分析，与分布式系统追踪类似，例如：

• network & console日志自动捕获
• 后端日志自动化收集
• 其他指标监控

第三阶段，我们需要自动化交互，并为自动化交互构建收集系统，这是自动化测试和监控的进阶，需要为LLM特别优化的输出才能得到足够好的效果

• 使用LLM进行评估（LLM-as-Judge）是一种AI-Native的方式，或许在Human alignement（对齐）上可以做到比较好，但仍然受限于简单任务，对于复杂任务人们很难模拟并自动化评估
• 由于复杂性，大多数产品不使用自动评估方法，而是通过研究员/工程师的自主洞见，或者设计信号（Signal），进行A/B实验来判断模型是否变好。Claude code“降智”事件可以看做是一次大型的量化模型A/B实验（有人有证据证明某些时间sonnet和opus是使用量化模型进行serve的，anthropic声称是Bug）

从我的理解上看，没有办法通过一个同等智能的模型评估另一个模型的思考过程，就如同使用AI检测AI一样，如果能被检测，那就一定能骗过检测，而当我们有更高级的智能来评估时，谁又来评估这个“更高级”的智能给我们带来了多少提升？最终我们只能达到两个结果：

1. 做了很多的事，得到了当前结果的算法验证，证明了目前的方法有用，可能产出一些对于当前方法为什么有用的洞见，仅此而已，并不对接下来的技术路线有指导意义
2. 仍然通过人类来探索新方向，评估永远滞后

既然评估只能解决一部分问题，我们应该做什么？或许我们不应该在现在开始研究评估，或许我们评估的目标并非中间产物

这一观察可能与我们目前正在AI Coding的前沿有关，我们很明显的碰到了LLM的能力边界，因此开始研究各种Context Engineering的方式，以及思考Context和LLM如何协作。因此我更倾向于将模块拿出来进行评估，衡量每个模块在任务过程中的成本和性能，而非优化出某种想要的结果。简单说，我们应该衡量我们驱动LLM的方式，通过A/B实验捕捉信号、还是通过定性定量分析，都是可以尝试的。

世界上大部分人没有用过AI Coding，以后的AI Coding也不会是现在这个样子

警惕局部最优

参考阅读

• X上的一些讨论：https://x.com/justinstorre/status/1964029634796015685
• A/B测试平台表示没有auto judge，全是监控：https://www.raindrop.ai/blog/thoughts-on-evals
• 系统性的评估是有益的：https://www.sh-reya.com/blog/in-defense-ai-evals/

我之前介绍过工程上的Context Engineering策略，而LLM进行工具调用的方式，目前看分为两种模式：

1. 检索模式：通过向量检索、搜索引擎等方式进行搜索，理解返回结果
2. 阅读模式：通过直接阅读文档进行理解

显而易见，检索模式效率更高，但容易受限于RAG等技术，精确度低，工程难度大，这种方式流行的原因其实是因为简单，而非性能。

目前看，阅读模式的性能更优，但实现上需要有更多考虑：一方面，上下文长度的控制和对应工具实现很重要，通常会提供类似grep、glob等工具来进行代码搜索；另一方面，通过sub-agent的方式进行上下文隔离，可以减少context的消耗。

未来如何

我们看到从输入的Prompt Engineering到Context Engineering，我们已经将对LLM应用从简单的汇编语言操作寄存器（仅有输入的prompt）进化到C语言类似的，可进行内存管理的高级语言模式，更进一步地看，下一步或许是发明更高效的编译器技术，让用户的自然语言能够更好地被高级语言所理解和编译，也就是说，Agent（LLM+工程）能够根据用户的输入来更加自主、智能地控制上下文。这是我认为的，除去预训练和记忆模式以外的另一种Learning实现。

我想起人们让Deepseek深度思考三秒后给出答案，Deepseek真的考虑一下什么是三秒，以及如何思考三秒。或许这就是肉身人类与硅基生命的区别。

时间是人类最重要的幻觉

认识到时间对于自己的重要性，是认识到自身意义的开始。

如果一个人一直按部就班地活着，时间对他来说是最不值钱的，相比之下，不被破坏的规律是他最重要的东西。

但某一天，突然发现，一个人的人生之所以不同，就是因为每个人所体验到的世界是独一无二的，而体验世界的唯一必须，就是时间。我们可以简单的说，时间之于物是没有意义的，物随时间变化形态，往往是相同或者相似的，如聚沙成塔、滴水石穿。但时间之于思想缺失最重要的元素，因为思想，所以感受到了时间，因为时间，思想得以发展。

对于物质的人而言，时间是人类最重要的幻觉

高考结束之后，人生仿佛按下了快进键，在大学卷，在实习卷，在工作卷，只有付出努力才能获得回报。

不论是在地铁、出游、还是在家里，我都在思考，思考着课程、作业、工作内容、架构设计、赚了多少钱，对比着自己和别人的生活，叹息着自己的生活不如意，于是又催促自己再加把劲。

或许我就是这样失去了发呆的能力。

我曾经认为，发呆是灵感的来源，是快速休息的方式，我总会在课堂上、公交车上、地铁上发呆，什么也不想，后来听说这叫正念，所以，我似乎很早很早就掌握了正念，又在忙碌中失去了它。

或许有人会说发呆和正念完全不同，但对我来说，发呆就是正念。

自从去年burnout之后，我开始慢慢地恢复到以前的状态，开始主动地放慢节奏，主动地观察内心，直到最近，我发现我的内心平静到一定程度时，我又找回了发呆的感觉。这是一种在放任思维流动的感觉，在这个状态下，我可以想象或者不想象、思考或者不思考，而回报是一时间的灵光闪现。

所以，多发发呆吧，如果发现自己无法发呆，或许是时候放慢脚步。

想想那个一十二岁的自己。

工具杠杆

从工具杠杆的角度上看，LLM是一个很平均的工具，在不对其进行微调的时候，人们总能通过chatbot提升自己的效率，但由于单纯聊天产生的价值不高，人们需要通过高价值的劳动行为来提升杠杆率。

目前得到验证的工具杠杆是Coding，在上一个时代（互联网时代）已经验证过，代码可以不间断的运行并带来价值，其边际成本极低，作为信息技术可以带来极大的杠杆率。如果我们可以使用LLM加速代码的生成，则可以利用互联网时代的基建和系统，提升整个互联网的发展速度

在其他领域上，比如PPT、AI员工等工作，我发现其缺少反馈环境机制，通常依靠人在回路进行反馈，也受限于人类认识和审美，这方面的最主要问题是人类缺少高质量的员工，而平均值的人类+平均值的AI并不能产生多少价值，也不能消灭多少岗位（因为AI的价格也很贵）。这很类似于以基本工资雇佣老头老太太来进行环卫、保安、售票员等工作，自动化本身的价格可能比他们还高或者持平，但是考虑到就业，社会不得不从经济效益和人的角度创造一些毫无意义的工作，这在任何行业都成立，比如互联网企业也存在一大堆的“职能岗位”，即便他们最擅长的就是用代码来提高效率。

知识杠杆

另一个想法是，LLM作为知识杠杆能够加速人类摄取知识的速度，从书籍与印刷业得到的启示是，当信息获取的成本降低后，社会效率会进一步提高。另一方面，科学上低垂的果实已经被消耗殆尽，越来越多的科研创新依赖着大组织协作，人们需要越来越多的时间来学习基础知识才能参与到科学创新中，如果我们可以加速人类摄取知识的速度，或许科学创新的速度也能被增加。

但科学创新的反馈链路太长，人类的经济制度是否能帮助这一过程，或者这是对未来的美好想象

二者结合

从我的角度上看，人类可能正处于从学堂学习到实践学习的转化过程中，只是没有人意识到这一件事。LLM最神奇的地方在于其工具属性和知识属性共存，以AI Coding举例，人们在使用LLM进行代码编写的过程中，也在和AI进行结对编程，学习相关的编程知识，那么为什么人类不能和LLM工具一起成长呢？

一个可能的问题是，知识杠杆由于当前的教育体制设计，其反馈回路太长，导致产品只能设计为“做卷子”（chatgpt study mode）的模式，而非渐进式学习的模式。人们总假设有一个固定的答案，而不是探索一个真实世界的解决方案，人们面向的销售目标也是在授课体制内的学生、老师和家长，而不是面临真实世界问题的每个普通人。

另一方面，LLM在工具中做的也不好，人们无法相信一个“自己都做不好”的老师，这一方面是LLM的幻觉与事实核查。另一方面是人类自己对于表达、理解和最重要的动力的缺失，很多时候人们已经被资本主义规训成“有自我”的人，虽然这个自我意识是千篇一律的，受到灌输的自我。我们称一个只知道享乐，不希望思考，使用产品的目的是“解决问题”的人为现代人，而称一个时刻都在思考解决问题的人为原始人，当我们用这一方式思考AI，人类居然妄想通过程序员、产品经理、测试人员的工作岗位划分Agent来模拟资本主义下低效的世界，将被规训的低智商人类映射到对真实人类智能仿真的神经网络上，果不其然极大地降低了LLM的智能。从这一角度上看，现在的人类头脑本身是非常适合和LLM共同成长的，而现存人类的肉体头脑因为其生存的时间长度，受到资本主义规训的影响，导致他们变成了“人力资源”而不是通用智能，则大大阻止了人类与LLM共同成长。

于是我发现，在下一代AI-Native人类成长起来（或许永远也成长不起来）之前，人们只能接受无脑产品或者研究机器，这一未来是光明的，但其曲折的过程，则是对于我们这一代人的局限和悲剧。

在传统的产品设计中，人们总是倾向于所谓的简洁，将一切复杂的原理藏在产品后面，让用户能够下意识的完成操作，人们总是假设用户无法理解产品背后的运行逻辑，不具备或不愿意花时间理解产品的技术细节。但在AI时代，每个人都需要通过表达来创造自己想要的东西，这时简洁反而成为了不安全感和困惑的来源。如果人们一定要面对复杂性，那么产品就一定要正确的暴露足够的细节，以便让人们能够更好地理解和掌握自己生成的东西的工作原理。

AI时代一个重要的改变是人们不再被专业知识而困扰，一个没有接触过web开发的非技术人士也可以通过大模型进行编码并部署在vercel之类的平台上，如果越来越多的人被纳入AI教育中，越来越多人开始使用AI，那么假设用户都是“不愿意学习的懒人”无疑是愚蠢的行为。基于这一假设，如果我们相信未来的世界是技术民主的，未来的人类是更会表达、更不机械、更有创造力的，我们就应该暴露更多的产品细节，创造更有可能性而不是更具可预测性的产品。

暴露错误是另一个让用户和产品一起成长的重要方式（还有一个是TODO Tool），通过精巧的设计，用户不再是对错误无能为力的人群，而是能够借助AI能力对错误进行修复并在其中成长的人，如果每个人都会有类似的成长过程，那么最适应这一成长过程的产品将会获胜，这或许是比“好用”更加重要的AI时代产品设计原则——成长性。

最后，通过成长性原则，我们可以帮助产品和用户建立起反脆弱的特点：从错误中学习并成长，从而出更少的错、创建更好的产品。由于AI的不确定性，随着AI的能力提升，产品对于AI的约束减少，产品的不稳定性也有可能上升(通常是AI和非AI的黏合初，很容易松动)，不同技能水平的用户使用其能力的方差应该也会增大，若可以实现一个机制帮助用户成长，那么我们就赋予了用户减少产品不稳定性的能力，从而实现用户和产品的结合，这或许是AI时代的用户粘性：不是chat、memory，而是experience point。