---
title: "2026.05.05 AI Agent 一些"
tags:
  - 日记
  - AI
  - Agent
  - 技术思考
---

2026.05.05 AI Agent 一些

尝试用AI搓了一版Agent, 我只是提出需求，剩下的都有agent自己完成。

验证了一些信息，Agent的出现实质上还是token变的便宜了。一次对话，从一次token,变成循环工具调用token，直到任务完成。

前些年的联网功能，也就内化成为Agent的一个工具部件。

而Plan模式的实质就是先把把这个循环过程，先预处理一轮，设定为多个小目标。这样的话，单次目标要处理的事情就更容易完成。

这一切的模式本质上都没有改变，大模型对话依旧是发送，返回。是无状态的。

现在看到的状态，比如记忆能力，比如循环调用，他和模型其实关系不大。

这也是存储如此昂贵，且肉眼可见的，需求会源源不断的增长的根源。



现行的优化需求，目前主要集成在实际的工程应用方面，ReAct 的实现并不复杂。

ReAct 运行之中的可靠性，解决上下文压缩和循环调度可靠性。

增加工具调用的方式，比如读取文本，读取上下文，索引，这些和Rag有关，但需要解决的地方有很多。

每次任务都携带庞大上下文的话，价格是一个很难解决的问题，这是使用API计费模式下的缺陷，早期是不存在缓存这个概念的。

Agent的出现，让多次调用的上下文，可以循环利用，大模型厂商，通过KVCahe，降低输入的成本，从而让Agent的实现成为现实，这也就是为什么CodingPlan出现的原因。

Copilot agent 按次计费 的设想是这样的，但实际中，一次agent, 可能会在循环中执行非常多的次数，所以最终CodingPlan 的计费模式被设定成 按总量计费，但存在小时和周的刷新。 

这确实破坏了用户体验，但考虑到本来就是补贴，所以是合理的。 

但一次复杂的任务，基本上必然会触及到刷新上限，这也迫使用户必须要付费更高的套餐以满足单独的需求。

一个复杂的任务，用户在输入的时候就做了拆分，到了Agent ,继续拆分成Plan ，在按照每个Plan实现。

应对的方案是号池。但这种在后续的性能优化中会降低。

---

OpenClaw模式的出现，其实是CodingPlan 催生出来，也是Agent模式下的必然。缓缓镶嵌。

DeepSeek的API 缓存命中和缓存不命中的区别，其实核心也是CodingPlan 的计费模式，几乎是一致的。

大量的缓存可以降低预处理的输入成本。代价是硬盘。

算力的Token优化的方案很多，TPU，AISC，等等专用芯片可以（对标国产显卡），这里存在巨量的优化空间。

但目前的瓶颈不在输出的Token，而在Agent模式下，多次循环调度，产生的巨量的输入，这些输入尽管通过缓存技术优化，但成本很高。

所以这是内存厂商，硬盘厂商，这一年股价上涨的根源。

----

小米的TokenPlan 有问题，消耗的太快，也就是虽然是Token Plan ，但实际上好像完全没有缓存层，于是我们看到的还是Token的消耗，而这在Agent模式下是知名的，也就是所谓的，对话一次，百万Token 。而一次简单的Agent，通常需要数十次，甚至数百次的调用。也就是出现工作时，小米的消耗越来越快，越来越快，从一次对话上下文比较少，到后期，常驻数十万token的时候，乘以数十次的调用。

而按照次数计费的Token ，典型的早期的GLM 和 MinMax ，这段时间涨价的Plan 。

----

对于大型项目而言，如果关联性很差，比如一个文件，数万行代码的时候，现有的方案，很难适配。

这也是Agent性能优化的核心。