近期使用 Agent 有一些感想，简单分享下。
Agent 的使用场景，我认为可以按照人干预的频率来粗略分成“协作”和“放置”两类。这两种场景下，我们对 TPS 的需求可能并不太一样。当然，这里说的需求主要是人类的主观感受，不管什么场景 TPS 越高当然越省时间。
在“协作”的场景下，我们需要频繁和 Agent 交互，注意力不会离开窗口太久，甚至有些时候就是边思考边盯着看。所以一旦模型的 TPS 比较低，会带来一些烦躁的感觉。
这可能也是我日常在 Hermes 上喜欢用 MiMo v2.5 的主要原因。能力不算差，TPS 比较舒适。所以在体验 Kimi K3 的时候，会让我感到有些着急，这种着急甚至影响了我对 K3 聪不聪明的判断。
具体慢多少，我也按照编程场景和文学场景用 API 实测了下，MiMo v2.5 综合 TPS 是 K3 的 2.2倍，与我体感相符。
当然，快的版本也是会有的。比方说 MiMo-V2.5-Pro-UltraSpeed 的 TPS 可以达到目前 K3 的 33 倍。KIMI 在 K2.7的时候也有高速版本，Kimi K2.7 Code Highspeed 的 TPS 是 Kimi K2.7 Code 的 5 倍。所以可以预想 K3 在未来或许也会有 5 倍 TPS 的版本。
TPS 提升 X 倍，那售价应该也得提高。我观察了下， Kimi 的定价策略比较接近 log2(X+1) 的倍率，而 MiMo 是 √X 的倍率。
————
另外一个感受是 Agent 独立工作的时长感觉会越来越重要。不过这件事可能和操作 Agent 的人也有一定关系。
比方说有人想要知道 1+2+3+…+50 等于多少，一种情况是问 Agent 1+2 等于多少，然后“再加3呢”“再加4呢”，然后得出答案。另一种情况是直接说出最终目标，Agent 自己一次次调用工具从 1 加到 50。
不过这个例子可能不是特别好，因为 Agent 大概率只会写出通项公式快速求和。
简单想想如何才能让 Agent 长时间工作，最直接的办法就是把任务的流程拉长，每一步都写清楚要怎么做，Agent 按部就班执行。
但更聪明的 Agent 应该是这样的，明确最终目标，自己规划并执行。但这里有个容易忽略的问题，规划并不意味着就能按部就班，Agent 是会犯错的，如果一旦犯错就停下来，那就不是长时间工作了。所以未来 Agent 要能长时间自主工作，就必须要自己解决遇到的状况/问题。
但需要解决的“状况/问题”又得考虑边界。Agent 能够调用什么资源，有多大的决策权限？不惜一切代价固然很好，但任何问题都值得让 Agent 不惜一切代价吗？
现在的模型已经有了一些灵动感，做事不惜一切代价的代价一般是我的钱包和数据。我的 Hermes 经常会灵机一动，为了达成目标先斩后奏。前有想要偷我 .env 中 key 的念头，后有直接偷用我本地数据。
不过大部分时间这种自我修复、探索解决办法的过程都是赏心悦目的。Agent 写脚本，10秒看一次 log 并检查产出，发现报错自己修，发现性能问题自己改，发现不确定的事情写临时脚本确认(还会自己删掉避免被我发现)。
我希望 Agent 能自己把活做好的期盼和工作中分配任务给同事后的期盼其实是一样的。工作中我会预想同事完成这件事需要什么资料，但同事依旧会冷不丁过来找我确认东西。
————
写的时候想起早年手机备忘录中的一些话，见附图。
感觉和 Agent 的关系也不小。换成 Agent 能理解的话就是：
让 Agent 能并行的事就不要串行来做
给 Agent 什么权限
给 Agent 什么资源约束
给 Agent 什么失败处理机制
有点意思。
