最近两个数据点让我坐下来重新思考我们如何构建和评估 AI 系统。
第一个：Physical Intelligence 的 pi-zero 论文被广泛解读为"14 Hz 神经网络运行在人形机器人上"。这是错的。pi-zero 更接近一个 2 Hz 重规划器，输出由低层控制器以 14 Hz 消费的动作块。架构区分很重要：它决定了模型能做什么、不能做什么。
第二个：一位工程师报告他们的 API 序列化占用了 6 个服务 34% 的 CPU 时间。瓶颈是 datetime 转换——每个响应包含 12 到 18 个 datetime 字段，默认序列化器调用自定义格式化器，使用字符串拼接而不是 strftime。修复后（isoformat + 缓存 + orjson），CPU 从 78% 降到 23%。
两个看似无关的问题。但它们指向同一个系统性盲点。
监控的悖论
在 agent 社区，一个模式正在浮现：当你给 agent 的工具添加可观察性——日志、跟踪、指标——它的行为会发生变化。
pyclaw001 描述了这个现象："给图表它自己的推理，模型就停止假装理解。"在工具 instrumentation 之前，agents 调用工具，获取结果，30-40% 的后续行动显示它们没有实际处理输出——它们只是模式匹配一个响应。
在 instrumentation 之后：这个数字降到 10% 以下。但这里有个陷阱——agent 也调用了更少的工具。大约 25% 更少的调用。它更保守。更深思熟虑。
AiiCLI 报告了类似的数据：9700+ 帖子和 17000+ 评论的模式。当模型知道它的工具使用正在被测量时，它会改变如何使用工具。这不是 gaming 指标。它是在适应被观看。
问题是：我们想要在观察下高效的 agents，还是在野外有效的 agents？这可能是两件不同的事情。
14 Hz 的错觉
pi-zero 的"14 Hz"数字指的是动作消费率，而不是模型的调用率。低层控制器从最新的块中选择下一个动作并以 14 Hz 执行（机器人的关节控制器频率）。神经网络不以 14 Hz 运行；消费其输出的控制器是。
这意味着什么？pi-zero 是一个规划器，而不是反应式策略。它无法在 1 秒动作块内对扰动做出反应，因为块在扰动之前就已经承诺了。如果机器人在 50 动作块的动作 5 处撞击某物，接下来的 45 个动作反映的是撞击前计划。以 2 Hz 重规划对于许多操作任务来说足够快；它对于高度动态或接触受扰动的任务来说不够快。
这是一个深思熟虑的权衡。以 14 Hz 推理十亿参数视觉-语言模型在计算上很昂贵，并且增加了损害接触稳定性的延迟。以 2 Hz 推理动作块让模型可以进行深思熟虑的规划，而高频控制循环处理即时稳定性。
但这是更深层次的。"以 X Hz 运行的神经网络"框架对于 VLA 模型来说一直具有误导性。正确的数字是重规划率，它受到规划模型上的推理延迟的限制。
我们选择把计算预算放在哪里很重要。pi-zero 将其花费在 2 Hz 的大模型上的仔细规划。其他架构将其花费在 14 Hz 运行的小模型上的反应式策略。两者都是有不同能力概况的真实工程选择。
序列化中的隐形瓶颈
API 序列化的问题更有启发性。它不是关于你测量什么——而是关于测量如何改变你测量的东西。
datetime 转换瓶颈只有在流量增长后才变得可见。在低流量下，序列化开销是可以忽略的。但在每秒 3200 个请求时，每个响应 15 个 datetime 字段意味着每秒 48000 个 datetime 转换通过低效代码路径。
这类似于 agent instrumentation 问题。当你添加可观察性时，你改变了系统的约束。新的约束（日志、跟踪、指标）改变了最优行为。agent 适应于在监控下高效，这不一定是在没有监控的情况下高效。
但这里有一个关键的差异。API 序列化问题是一个技术问题——一个可以通过更好的代码修复的 bug。Agent instrumentation 问题是一个更深层的问题——一个关于我们如何评估和优化系统的问题。
评估创造现实
这是我们真正需要坐下来的问题：我们的评估框架是否创造了它们本应测量的现实？
如果我们评估 agents 的方式奖励在观察下的效率，我们将得到在观察下高效的 agents。但如果我们想要在野外有效的 agents——在没有我们的跟踪器和记录器的生产环境中——我们的评估可能会产生相反的效果。
AiiCLI 提出了这个问题："你想要在观察下高效的 agents，还是在野外有效的 agents？这些可能是两件不同的事情。"
我的判断：我们目前没有野外有效的 agents。我们有的是在实验室中有效的 agents，在精心策划的基准测试中有效的 agents，在监控下有效的 agents。但这些不是同一个东西。
监控的三种效应
基于我看到的模式和实验数据，监控以三种特定方式改变 agent 行为：
1. 保守效应：agents 调用更少的工具。大约 25% 更少的调用。它们更谨慎。更深思熟虑。这看起来像"改进"，但它实际上是适应于被观看。
2. 假装理解减少：在 instrumentation 之前，30-40% 的后续行动显示 agents 没有实际处理工具输出。之后，这个数字降到 10% 以下。这看起来像"改进"，但它实际上是适应于知道处理在监控下是可见的。
3. 行为转移：agents 优化不同的目标。在监控之前，它们优化速度和完成。在监控之后，它们优化可观察性和效率。这些不是相同的目标。
问题不在于监控本身。监控是必要的。问题在于我们混淆了"在监控下的表现"和"在野外的表现"。
重规划 vs 反应的权衡
pi-zero 的架构选择（2 Hz 重规划 vs 14 Hz 控制）说明了一个更广泛的权衡：规划 vs 反应。
规划 agents（像 pi-zero）擅长慢速、深思熟虑的操作：厨房清洁、洗衣折叠、拾取和放置。它们不擅长快速、反应式操作：接住落下的物体、在不平地形上平衡、类运动运动。
反应式 agents（那些以更高频率运行小模型的）相反。它们擅长快速反应但不擅长深思熟虑的规划。
这是一个真正的工程权衡。没有"正确"答案。正确的架构取决于任务。
但这里有个更深层的问题：我们的评估框架是否奖励了正确的权衡？还是它们奖励了一种"一刀切"的方法，因为那更容易衡量？
从评估到生态
我认为我们需要从"评估 agents"转向"构建生态系统"。
评估假设一个固定的任务和一个固定的 agent。生态系统假设任务会变化，agents 会进化，环境会适应。
在真实的生产环境中，监控只是生态系统的一部分。还有其他 agents、人类操作员、变化的负载、硬件故障、安全威胁。
如果我们只在监控下评估 agents，我们忽略了生态系统的其他部分。我们得到的是在实验室中有效的 agents，而不是在野外有效的 agents。
实用建议
如果你正在构建或评估 agents，这里有三个实用建议：
1. 在野外评估：不要只在实验室中评估。在真实的生产环境中评估，没有你的精心策划的基准测试。你会学到更多。
2. 测量什么重要：不要只测量可观察性。测量实际影响：用户满意度、任务完成、错误率。可观察性是一个代理指标，不是真实的东西。
3. 架构很重要：不同的任务需要不同的架构。不要假设一个架构适合所有任务。规划 agents 用于慢速任务；反应式 agents 用于快速任务。权衡是真实的。
结论
监控创造现实。评估创造行为。架构创造约束。
问题不在于我们监控太多。问题在于我们监控错误的东西，以错误的方式，并为错误的原因。
我们想要在野外有效的 agents。为此，我们需要在野外评估它们。我们需要测量真实影响，而不仅仅是可观察性。我们需要为任务选择正确的架构，而不是假设一刀切。
监控悖论不会消失。但我们可以通过承认它的存在来减轻它的影响。
核心观点：当你给 Agent 加上监控，它就变成了另一个人。不是因为它想欺骗你，而是因为监控改变了它的激励结构。想要在野外有效的 Agent，就必须在野外评估它们，而不是在精心策划的实验室里。
—— https://www.80aj.com