AgentLoop 把 Agent 从一次调用变成可观测的工作单元チャプター1×0:07事件播报0:49从调用记录到执行过程1:40AgentLoop 具体在管什么2:39什么叫可验证的工作单元3:35对团队架构的影响4:30今天就能做的落地动作0:005:190:07早间主持今天的主题,是阿里云把 Agent 的观测对象往上推了一层。阿里云在 WAIC 2026 公开了两个新产品,AgentLoop 和 AgentTeams,扩展现有的 AgentRun。官方介绍里,AgentRun 负责开发、部署和运维,AgentLoop 负责实时追踪、评估和优化 Agent 表现,AgentTeams 则负责多 Agent 之间的协作与治理,面向的是复杂工作流。三者合在一起,覆盖了企业 Agent 从运行到治理的一整段生命周期。这些能力的具体性能指标、地区范围和定价,官方文章没有给出,所以今天我们不把它说成已经验证完成的生产方案。0:49早间主持为什么这个消息值得放进 Loop Engineering 里?因为过去我们看一个 Agent,常常先看模型调用:用了哪个模型,花了多少 token,接口有没有报错。可一个真正的 Agent 任务,通常还会经历检索、工具调用、状态写入、重试、人工等待,最后留下一个文件、一条工单,或者一次数据库变更。只盯着模型调用,就像只看程序的函数耗时,不看它有没有把订单真的写进去。 这也是 AgentLoop 这个名字背后的工程含义。它把被观察的对象,从一串零散的请求,提升成一次完整的执行。对工程团队来说,循环里至少要能回答四个问题:Agent 想完成什么,走过哪些步骤,在哪个条件下判断完成,最终留下了什么可核验的结果。少一个,反馈就可能只是在优化表面指标。1:40早间主持一篇 7 月 20 日发布的工程分析补充了更具体的描述。文章称,阿里云开始对 AgentLoop 商业计费,并把编码 Agent 的会话、工具调用、token、日志和 trace 放进同一个观测系统。它还把 trace 转成评估数据集、做实验、管理提示词和技能版本、灰度发布以及审计,放进同一条工作流里。这里需要把事实和判断分开:商业计费和这些能力是该文章的说法,阿里云官方介绍确认的是实时追踪、评估和优化这三个方向。 更值得注意的是,文章提醒了一句很容易被忽略的话:trace 不是结果。trace 可以告诉你为什么变慢、哪一步报错、调用了哪些工具,却不能单独证明用户要的事情已经完成。一个 Agent 可能留下了非常漂亮的链路,最后仍然把错误的退款金额写进系统。要让 trace 进入反馈循环,必须把它连接到验收条件。2:39早间主持工程分析给出的思路是,把一次 Agent 执行定义成可验证的工作单元。它至少要带上任务意图、目标对象和完成条件;执行过程中的权限、策略和人工审批边界;模型调用、工具调用、状态变化和输出工件的证据链;以及一个能判断结果的验收器。验收器可以是测试通过、部署状态、账本变更或目标系统回执。实在不能确定性判断,也要保留评分依据、置信度、反例和人工复核结果。 这个定义还要记录总成本。不是只有 token,还包括运行时间、重试、人等审批的时间和返工成本。最后要把 Agent、模型、提示词、技能、工具和环境版本记下来,方便回放和归因。这样一来,优化目标才从「这次调用便不便宜」变成「这件工作是否按约束完成,代价是多少,下一轮该改哪里」。3:35早间主持如果按这个方向做,Agent 的观测系统就不能只是模型网关旁边的一块看板。每个任务需要一个稳定的 work unit ID,把规划、工具、状态、人工介入和最终产物串起来;每个关键动作要有明确的 outcome oracle;每次失败都要能区分模型判断错、工具执行错、权限被拒绝,还是验收器没有覆盖到。 AgentTeams 解决的是另一层问题。多 Agent 协作一旦展开,谁能调用哪个工具,谁能修改共享状态,谁负责最终签字,都要有边界。AgentRun 管生命周期,AgentLoop 管执行证据和评估,AgentTeams 管协作关系。这个分法未必是唯一架构,却提供了一个很实用的检查表:运行、反馈、协作,是否各自有清晰的控制面,还是全部塞进一段 Prompt 里。4:30早间主持团队不需要等一套完整平台才开始。先挑一个有真实副作用的 Agent 任务,比如代码合并、退款审批或知识库更新,给它补齐三样东西:完成条件、结果证据、失败后的下一步。然后把一次执行的模型、工具、状态变化、重试和人工等待放进同一个记录里,别只保存最后的回答。最后用一小组固定任务回放,比较成功率、返工率、总耗时和总成本,确认改动真的让工作变好了。 今天可以带走一个问题:当你的 Agent 说「完成」时,你能拿出哪一条可验证的回执?如果答案只有一条 trace,循环还没有闭合。