AI ODYSSEY · 观察日记
模型要走得久，周围就得先长出一套能追踪、能验收、也能停下来的系统。
Cloudflare 连续发布了五篇博客，内容从 Agent tracing、CI SDK，一路写到 Agent Development Lifecycle。放在一起看，它们更像是在给 Agent 修一座软件工厂。
其中有个细节很具体。Cloudflare 在 Astro 的 GitHub 仓库上运行了一套自动 triage 流水线，把 200 多个开放 Issue 降到约 30 个，并预计在下个月清零。Issue 被打上标签后，隔离的 AI 子代理会复现问题、诊断原因、修改代码，再自动生成预览版本交给用户确认。
以前我们看 coding agent，经常盯着它能不能写出一段代码。现在它开始接一张工单，穿过复现、修复、测试和反馈，再把结果送回用户手里。代码只是流水线中间的一站。
一个 Issue 被拆成了整条生产线
Cloudflare 把这套思路称为 Agent Development Lifecycle。这个名字听着有点 PR，但里面的问题蛮真实：当 Agent 连续跑几个小时甚至几天，团队需要知道它调用了什么工具、在哪一步失败，也需要在结果失控前把它拦下来。
因此，Cloudflare 同时推出统一的 Agent 会话视图和基于 OpenTelemetry 的追踪能力。模型调用、工具执行和报错都会留下记录。本地调试也开始自动采集 trace，让 Agent 读自己的运行痕迹，再修复环境并重新验证。
「Agent 工程正在从让模型会做事，走向让组织敢让它做事。」
我很认同这种工程方向。模型表现再好，只要工作过程完全不可见，团队就很难把重要任务交出去。一个偶尔犯错的同事并不可怕，可怕的是没人知道他改了哪里，也找不到事情从哪一步开始跑偏。
后者没有那么炫，却会决定 AI 能不能进入公司的日常流程。
自动化开始离开代码编辑器
今天另一条让我有些意外的消息来自面壁。团队在官方公众号介绍了 ForgeStencil：Kernel Agent 和 App Agent 自动协作，一周内优化了 100 多个工业与科学软件，并走完从算子优化到应用集成的流程。官方称全程零人工介入。这个数字当然要结合具体任务看，但自动化的边界确实在往外走。
代码 Agent 以前比较像坐在编辑器里的助手。ForgeStencil 展示的方向，是让多个 Agent 围绕性能目标反复实验、部署和调整。它处理的不是“帮我写一个函数”，而是“把这套软件跑得更快”。目标可以测量，模型也更容易形成闭环。
另一边，模型运行本身也在变轻。Swiftlet 的 GitHub 仓库展示了在 Mac 上以约 4.3 GB 内存运行 80B 版 Qwen、在 iPhone 上运行 35B 版的方案；AirLLM 则尝试用 4 GB 显存运行 70B 模型。这不代表普通用户已经可以无感使用大模型，但我会有点期待这种变化。模型逐渐离开昂贵的集中式机房后，小团队对 数据、成本和部署会多一些选择。
能力扩散以后，控制变得很具体
Agent 进入真实世界，控制就不再是一句抽象的安全口号。EA 首席战略官 Mihir Vaidya 在 Runway 的访谈里提到，生成式 AI 进入游戏要面对每秒 60 帧、数千玩家同步和低延迟。画面合理还不够，角色行为也要稳定、可控。他把“控制”视为接下来的技术边界，我很认同。
游戏角色走错路，可能只是让玩家出戏。自动驾驶、工业软件或企业数据流程出了错，代价会具体得多。中国 L3/L4 自动驾驶强制性安全国标今天发布，也在表达相似的现实：能力可以快速进入产品，责任必须被写进测试、准入和运行边界里。
昨天读模型发布时，我感受到的是能力正在变便宜；今天再看这些工程新闻，才觉得 信任也在变成一种需要建设的产品。它由日志、评估、权限、回滚和人的签字一点点组成，不会随着模型升级自动出现。
软件工厂可以一直运转，任务也可以被切给更多 Agent。人的位置没有因此变轻，只是从亲手完成每个步骤，慢慢移到了定义边界、读懂痕迹和承担结果上。技术把执行拉得很长，也让责任留下了更清楚的形状。
