本轮先检索北京时间11月3日执行前24小时，再扩展到48小时。合格一手更新集中在11月2日和11月1日。今天最值得企业知识库负责人关注的变化是：数据智能体终于开始把“每次会话用了多久、花了多少、有没有人用”放进正式可观测范围。但企业验收不能止于一张成本图。一次会话是否值得，必须同时回答四个问题：引用了什么证据、执行了哪些模型和工具、消耗了多少资源、最后有没有完成业务任务。
今日重点
- 数据智能体可以按会话看性能、采用、延迟和成本。Google Cloud 11月2日宣布，BigQuery中的数据智能体及其会话可借助Google Cloud Observability监控上述指标，功能已正式可用。需要关注的是知识库负责人、数据平台负责人和财务运营团队；未知边界是平台指标并不会自动告诉你引用是否正确、权限是否越界。
- 领域知识开始被整理成可供智能体调用的上下文包。同日，Google Cloud将Knowledge Studio置于预览，可从数据资产、语义关系、查询日志等信号中整理领域知识，并打包为context sets，通过MCP或API支撑智能体。它仍是预览能力，且“上下文已接入”不等于“答案已核验”。
- 数据工程智能体开始生成含AI、ML和对象处理的流水线。Google Cloud同时宣布Data Engineering Agent支持在Dataform SQLX流水线和指令文件中使用BigQuery AI、ML及对象函数与语句，功能正式可用。企业要关注生成逻辑、数据权限、成本上限和回滚，而不是只看能否生成代码。
- 既有审批工作流可以作为智能体工具继续使用。AWS 11月2日说明，Step Functions工作流可通过AgentCore Gateway作为MCP工具暴露给智能体。智能体决定何时调用和输入什么，资格校验、经理审批、执行顺序仍由既有工作流控制。它有利于受控执行，但工具授权和参数仍要单独验收。
- 跨区域智能体可以携带用户身份，而不是退回宽泛角色。AWS IAM Identity Center支持跨区域可信身份传递，让请求在另一地区继续以用户或群组维度授权和审计。多区域知识库要验证身份映射、撤权传播和失败降级，不能把“身份可传递”写成“权限天然正确”。
- 单GPU共享更适合小模型与多模型服务，但不等于推理质量提升。Amazon ECS开始支持NVIDIA MPS，让多个任务并发使用一张GPU，并可声明显存和计算份额。它可能改变边缘推理或工业视觉服务的资源配置；实际吞吐、尾延迟、显存峰值和故障隔离仍需在目标模型上测量。
- 实时会话客户端修复了WebSocket连接与认证配置问题。OpenAI Python SDK v3.42.1于11月1日修复Responses WebSocket连接行为，并增加beta认证配置校验。使用实时语音或流式智能体的团队仍需测试断线重连、重复响应、事件乱序和幂等。
- 基础设施追踪可以贯穿负载均衡器到后端。Google Cloud的应用负载均衡器分布式追踪进入预览，可生成符合W3C Trace Context和OpenTelemetry的追踪跨度。它有助于定位网络和后端延迟，但不能替代模型、检索、工具和业务结果的应用层追踪。
本轮未找到同一24至48小时内、同时具备一手材料并足以改变采购或验收决策的工业视觉算法、机器人或AI芯片专门发布；因此不以旧闻补齐栏目。GPU共享只作为推理基础设施变化，不包装成视觉精度提升。
重点拆解：一条会话要有四本账
企业知识库最常见的成本口径，是把月度模型账单除以问答次数。这个数字容易算，却很难决策：同样一次问答，有的只查一段制度，有的检索十个库、重排几十个片段、调用审批工具，还需要人工复核。若只看平均Token，低价值闲聊和高价值流程会被混在一起，团队也不知道该优化检索、模型、工具还是人工环节。
更可用的办法是给每条会话建立四本关联账。
第一本是任务与身份账。记录会话ID、业务意图、用户角色或经过脱敏的主体标识、租户、权限路径和开始结束时间。标签必须是稳定枚举，不能把完整问题、客户姓名或敏感内容塞进监控标签。只有任务归类稳定，才能比较“制度查询”“售后诊断”“报价辅助”等不同意图的成本与成功率。
第二本是证据账。记录检索查询、数据源、文档ID与版本、片段定位、权限过滤结果、重排顺序、引用是否被最终答案采用。这里不要求把所有原文复制到日志，但必须能够回到当时版本。否则会出现今天回放时引用正确、实际回答当时却引用旧文档的假象。
第三本是执行账。把嵌入、检索、重排、生成、缓存、工具与工作流分别记录：模型或服务版本、输入输出规模、P50/P95/P99延迟、重试、错误码、超时、人工接管和工作流运行ID。基础设施追踪可以解释请求卡在哪里；应用追踪还要说明为什么调用、传了什么范围、结果是否被采用。
第四本是结果账。至少区分任务完成、部分完成、未完成、拒绝、人工接管和用户放弃。对售后场景可以记录问题是否定位，对制度问答可以记录引用是否足以支持答案，对审批辅助可以记录是否进入正确下一步。点击咨询入口只能记为入口点击，不能直接算有效咨询。
四本账用同一个会话ID或可追踪的父子ID关联，就能把“快不快、贵不贵、答得对不对、有没有用”放在一起。Google这次新增的是重要的第一步：会话级性能、采用、延迟和成本。企业仍需补上证据与结果两端，才能形成真正的验收闭环。
成本公式要把隐藏环节写出来
单次会话成本可以按下式拆开：
会话成本 = 嵌入 + 检索 + 重排 + 生成 + 工具/工作流 + 缓存与存储 + 可观测性 + 人工复核。
这不是固定报价，只是归集框架。每项都应写明计量单位和假设。例如向量检索可能按节点与存储计费，生成按输入输出规模计费，工具可能按调用次数或运行时长计费，人工复核按角色与处理时长估算。共享GPU也不能简单把整机成本平均分配；应按声明份额、实际占用、等待时间和故障冗余建立项目口径。
更有用的派生指标是“每个成功任务成本”，即合格完成的会话总成本除以成功任务数。若成本下降但引用错误、权限拒绝或人工接管增加，优化并未成功。反过来，某类复杂任务单次成本较高，但能稳定完成原先需要人工多轮处理的工作，也可能值得保留。
白泽的企业RAG开发服务可围绕检索、权限、引用、工具和验收口径共同定义范围；知识管理主导的项目也可核验企业知识库开发服务。本篇没有可公开证明“按会话观测后节省多少”或“转化提升多少”的白泽案例，因此只提供方法，不冒充项目成绩。
从监控到验收，至少做三组对照
第一组按业务意图分层。不要把所有会话混成总平均值，而应分别查看高频查询、复杂检索、工具执行、权限拒绝和人工接管。每组都报告样本量，样本不足时标记待观察，不能用一个异常会话判断模型优劣。
第二组按结果分层。成功、部分成功和失败会话分别比较成本与延迟。尤其要观察失败会话是否反复检索、重复调用工具或在工作流入口前循环。只有失败更便宜并不够；还要确认系统能尽早识别边界并转人工。
第三组按版本分层。检索配置、提示词、模型、工具和知识库索引任一变化，都要进入版本标签。发布前用同一批脱敏样本做回放；发布后再看真实会话分布。建议示例批次可从20至50条起步，但这只是测试设计假设，不是行业标准，也不是白泽真实报价或成绩。
验收表至少包含：引用正确与可回溯、权限越界为零容忍项、任务完成定义、P95端到端延迟、工具错误和重试、每个成功任务成本、人工接管原因、回滚是否有效。原始问题和回答若涉及商业秘密或个人信息，应留在受控审计存储，监控平台只保存必要元数据和脱敏关联键。
今日企业行动
- 先统一会话ID与任务标签。把网页、知识库、模型、工具、工作流和人工接管串到同一条追踪链；标签不放敏感原文。
- 把成本与成功结果配对。先选一个高频业务意图，拆出检索、模型、工具和人工成本，同时定义什么叫完成。
- 做一次分层回放。从20至50条脱敏样本开始，覆盖正常、越权、旧版本、工具失败和人工接管，比较版本变化而非只看总平均。
准备评估企业知识库时，可先整理文档规模与更新频率、角色权限、典型业务意图、工具与工作流、可接受延迟、人工接管规则及当前费用来源。白泽智能｜重庆斯巴达信息技术有限公司将据此把成本、证据与业务结果写进同一份验收口径，不承诺固定节省比例、搜索排名或咨询数量。
来源与证据边界
Google与AWS条目属于厂商发布，正式可用、预览、性能与价格口径按原文区分；本文关于企业验收的四本账、成本公式与抽样方法是工程建议，不代表厂商承诺或白泽既有项目成绩。