Agent 上线后谁在“留证”？一项平台更新，暴露企业智能体的真正迁移成本

一套智能体从演示走进生产，最先丢失的往往不是模型能力，而是“它刚才为什么这样做”的证据。7月23日，AWS 为 Bedrock AgentCore 更新了统一可观测性：Agent 的追踪、提示词、输入输出和普通日志可以进入同一个、按 Agent 划分的日志组；新建 Agent 默认启用。与此同时，AWS 文档显示，旧版 Bedrock Agents 将在7月30日停止接受新客户。两条信息放在一起看，提醒企业：迁移不是把提示词和工具接口搬到新平台，而是把每一次执行的证据链一起搬走。

真正可运营的智能体，不只要交付结果，还要能回答：读了什么、调用了什么、依据何在、谁批准了、出了问题怎样还原。

从“看见日志”到“拥有一份执行档案”

过去，排查一次异常回答常要在多个监控入口来回检索：一处是链路追踪，一处是运行日志，一处才可能留着模型输入输出。AWS 此次把这些遥测数据聚合到单个 Agent 的日志域，并支持以 IAM 权限和客户管理密钥分别保护，技术动作很小，管理含义却很大：企业可以开始把“某个 Agent 的完整执行历史”当成一个独立的运营对象。

这比仪表盘多几个图表重要得多。客服 Agent 错发了一次退款、营销 Agent 引用了过期资料、采购 Agent 把合同交给了错误审批人，管理者需要的不是“本月成功率 92%”，而是一段可以回放的事实：它接收的任务是什么，检索到哪些知识，经过了哪些工具调用，在哪个规则或人工关口被放行。没有这些证据，所谓优化只能靠猜；没有按身份隔离的访问边界，所谓审计又会变成新的数据暴露面。

7月30日之后，别只做“功能等价”迁移

AWS 已提示 Bedrock Agents Classic 不再向新客户开放，建议新需求转向 AgentCore。类似的平台迭代会越来越频繁：模型会换、编排框架会换、连接器会换。企业若把迁移清单只写成“提示词、知识库、工具、权限”，上线后很容易发现历史评估样本、失败案例和审计记录留在了旧系统，新的 Agent 虽能工作，却失去了继续变好的参照系。

我建议在任何 Agent 迁移项里加上第五类资产：运行证据。至少包含四组内容：任务版本与预期结果；可检索知识及其版本；执行轨迹、工具调用和人工接管点；失败样本与处置结论。前两组让你知道 Agent “应该如何做”，后两组让你知道它“实际上做了什么”。两者合在一起，才是可复用的生产经验。

企业可以从一张“留证清单”开始

这张清单并不要求企业先买一套大而全的治理平台。可以先挑一个高频、但仍有人工复核的流程，例如内容审核、售后分类或销售线索整理，把一次任务从触发到复盘的证据串起来。等团队能稳定解释“为什么这次结果可信”，再扩大自动化范围。这样扩大的不是黑箱调用量，而是组织对智能体的控制力。

STARBOX视角：把运行痕迹沉淀回组织，而非留在某个工具里

我们在服务企业内容与营销工作流时看到，真正难迁移的从来不是一个提示词，而是“什么算好、谁有权放行、为什么上次没通过”的集体判断。STARBOX 的组织—BOX—智能体三层架构，正适合承载这类资产：组织层定义目标、品牌规则和审批边界；BOX 层沉淀客户旅程、知识、任务卡和评测样本；智能体层在清晰授权内执行，并把结果送回 DDABC 闭环。

今天的统一日志更新，给了一个很实际的信号：平台会替你收集数据，但不会替你定义哪些记录值得成为组织经验。企业要主动把“任务—证据—判断—改进”设计成自己的标准。这样即使更换模型、供应商或框架，持续优化的能力仍然留在自己手里。

下一次评估智能体项目时，不妨少问一句“它能做多少事”，多问一句：“三个月后，我们能不能清楚还原它为什么做对，又为什么做错？”能回答这个问题的团队，才真正拥有了可规模化的智能体能力。

信息来源：AWS《关于 Amazon Bedrock AgentCore 统一可观测性的公告》（2026年7月23日）；AWS Bedrock Agents 文档（2026年7月，Classic 停止接纳新客户说明）；AWS AgentCore 2026年7月发布说明。