阅读

中国科技公司百度于2026年11月12日在其年度世界大会上发布了最新的基础模型ERNIE 5.5 Flash Preview，并推出了一个名为“Token Exchange”的新市场平台，旨在连接AI模型服务提供商与客户。此次发布还包括对其智能体产品线的重大升级，以及百度创始人兼CEO李彦宏关于“智能组织”愿景的阐述。

ERNIE 5.5 Flash Preview是一款拥有2800亿总参数、每次推理激活140亿参数的混合专家（MoE）模型，支持100万token的上下文窗口。百度称该模型在编码、3D建模和内容创作方面表现强劲，并采用了专有的递归自我改进技术ERNIE Evolve以优化推理效率。值得注意的是，百度公布了明确的API定价：每百万输入token价格为1元人民币，输出为4元人民币，缓存输入仅为0.04元人民币。模型权重将于11月25日开源。这一激进的价格策略表明百度正试图通过降低使用门槛来扩大其大模型生态的市场份额。

除了模型本身，百度推出的Token Exchange是一个中立的模型服务交易市场。客户可以在这里比较不同模型的性能和价格，并通过单一入口访问服务。据百度介绍，该平台上线一个月以来已接入超过100个模型资源，日均处理超过5000万次调用和7000亿token。这一举措意在解决高质量模型服务难以发现和使用的痛点，同时也可能帮助盘活闲置算力。

在内部应用方面，李彦宏披露了百度向“智能组织”转型的具体进展。过去一年，百度内部的日均活跃智能体（DAA）数量从5,000个激增至37,000个，增幅超过600%；每周由智能体完成的任务量也从84,000次上升至超过100万次。这些数据为投资者提供了观察百度如何将AI技术转化为实际生产力和运营效率的内部视角。此外，百度还升级了其通用智能体DuMate、数字人智能体百度一镜等产品，并展示了昆仑芯的新路线图。

一个小型模型被要求安装一个工具，它回答：'你有大脑而我没有。'Dell Pro Precision工作站AI策略负责人Logan Lawler在博客中回忆了这个测试经历——工具链已经把安装所需的全部信息喂给了模型，模型却完全无法理解任务。这个轶事引出了他的核心判断：在智能体等于模型加工具链这个公式里，模型是大脑，而错误的大脑即使拥有一切必要条件也会失败。

他的方法分三步。第一步，从基准网站建短名单。他推荐四个：Artificial Analysis用独立测试比较质量、价格和速度，适合按预算筛选；Arena（原LMArena）让真人匿名对比两个模型的回答并投票，反映日常写作和问答中的实际偏好；Berkeley函数调用排行榜测试模型使用工具（搜索、文件访问等）的准确度——智能体通过工具完成工作，所以这个榜单对智能体场景最关键；SWE-bench测试模型能否修复开源软件中的真实bug，适合需要写代码的智能体。第二步，在真实任务上跑对比。Lawler建议用OpenRouter账号（一个账号访问多家提供商的模型）或LM Studio（在本地加载模型）各试一个前沿模型和一两个小模型，对同一条任务跑两到三遍。第三步，按四个维度打分：是否完成、是否正确、需要多少反馈、花了多少钱。保留最便宜的合格模型。

打分之后是路由。Lawler引用了一个具体数据：LangChain在145个智能体任务上测试NVIDIA NeMo Switchyard路由库，只有7%的步骤需要前沿模型。这意味着绝大多数日常步骤——调用工具、总结结果——可以由小模型完成。他的个人生产配置是：设计智能体和编写技能时用前沿模型（通过OpenRouter和Claude计划），因为那是'需要付费的硬思考'；技能建好之后，每天运行在DeepSeek V4 Flash上，部署在一台Dell Pro Precision GB10工作站上。

Lawler也划出了边界。如果对比测试显示只有前沿模型能把任务做对，或者任务属于最难的编码、推理或研究类型，就不要强行用开源模型。他的原话是：'别把开源模型逼进一场它目前还赢不了的比赛。'他还强调自己一直在测试，建议读者一个季度后再来问。

需要注意的语境：本文发布在Dell Technologies官方博客上，作者的工作职责是领导Dell Pro Precision工作站的AI策略，文中推荐的NVIDIA Nemotron系列模型、NeMo Switchyard路由库和Dell GB10工作站均与其商业利益直接相关。LangChain的7%数据来自其测试NVIDIA Switchyard路由库的结果，不是独立第三方评估。方法论本身——建短名单、跑对比、按四个维度打分、留最便宜的——是可迁移的，但具体工具推荐应视为带有厂商立场的建议。

跨组织的多代理系统面临一个具体约束：两家机构各自构建和运行代理，它们需要发现彼此、交换任务，但不能暴露内部实现，也不能要求双方使用同一框架。没有标准化协议时，每增加一个客户或框架组合，ISV 就要编写一套定制集成代码。A2A 协议试图用单一接口替代这些路径。

AWS 机器学习博客给出的参考架构在两个独立 AWS 账户中运行三个代理。企业侧的编排器基于 LangChain，调用 Anthropic Claude Sonnet 4.6 做推理路由；SaaS 侧的合规代理基于 Strands Agents SDK，部署在 Amazon Bedrock AgentCore 上。两者使用完全不同的框架和 SDK，但通过 A2A 的 JSON-RPC over HTTP 通信。编排器不依赖 Strands SDK，合规代理也不依赖 LangChain——这是协议级互操作的实际含义：只要双方都讲 A2A 并发布兼容的 Agent Card，框架可以各自更换。

Agent Card 是这套机制的核心发现层。它在 /.well-known/agent-card.json 路径发布一份 JSON 文档，描述代理的名称、能力和技能。编排器在启动时拉取这张卡片，为卡片上每个技能创建一个 LangChain 工具，之后由大语言模型根据用户问题决定调用哪个工具。这意味着 ISV 添加或修改能力时，只需更新 Agent Card，编排器下次重启自动获取新技能，两个团队无需协调代码变更。

关键的设计决策在于卡片发布什么。合规代理内部有三个工具（列出账户、执行扫描、获取修复步骤），但 Agent Card 只发布一个策展技能：「扫描你的 AWS 账户，按严重性返回发现项和修复步骤」。调用方的模型看到的是产品做什么，不是怎么做的。这层抽象让 ISV 可以重构内部架构——换模型、换工具、换实现——只要卡片描述的技能不变，客户集成就不受影响。

双向回调是这套方案超出典型代理演示的地方。大多数代理间通信展示的是单向请求-响应：客户端调用服务端代理，等待结果。但当被调用的代理需要只有调用方才有的信息时，这个模式就失效了。在这个架构中，合规代理在扫描前需要企业上下文——哪些账户是生产环境、适用哪些内部策略、向谁升级——这些信息只有企业侧知道。合规代理通过 A2A 回调到企业上下文代理，使用自己账户的身份提供方获取令牌，向客户在入驻时注册的回调地址发送消息。这使两个代理成为真正的对等体，而非客户端和服务端。

认证方面，每个账户有自己的 Amazon Cognito 用户池，双方各自从自己的池获取令牌，接收方只信任对方池发出的令牌。入驻时双方交换的只有公开值——身份提供方 URL、客户端 ID、作用域和端点 URL——不共享任何密钥。每个 A2A 任务请求携带 JWT，接收方验证签发方、客户端和作用域。唯一不需要认证的端点是上下文代理的 Agent Card，因为它只发布描述性元数据。

端到端测试验证了整条链路：编排器发现合规代理、路由请求、合规代理回调上下文代理获取账户元数据、执行扫描、返回包含两个代理数据的富化报告。测试通过的条件是回复中包含合规发现、包含只有上下文代理知道的值班轮换代码，且合作伙伴 API 访问日志记录了回调客户端的 200 响应。随后七项信任边界检查确认每个令牌只在被信任的位置有效，错误、缺失或伪造的令牌均被拒绝。

这套参考实现的适用边界值得注意。它使用合成数据模拟合规发现，未展示生产环境下的延迟、吞吐或故障恢复表现。双向回调模式要求双方各自维护身份提供方配置和回调注册，运维复杂度高于单向调用。博客本身也列出了生产化建议：按客户拆分运行时、用密钥认证替代客户端密钥、启用 PrivateLink 和 KMS 加密、配置 VPC 流日志等。这些说明当前架构是模式验证，不是可直接投产的成品。

对读者的实际意义在于：如果组织正在构建需要跨团队或跨公司协作的代理系统，A2A 的 Agent Card 发现加双向 OAuth 回调提供了一种替代定制集成的路径。它不要求双方使用同一框架，不要求共享密钥，能力扩展通过更新卡片而非修改调用方代码完成。但这条路径的前提是双方都接受协议约束并各自维护身份基础设施——这本身是一项运维承诺。

一个内部HR政策助手，回答三个问题：绩效评估、福利登记、病假证明。chunk级检索精度——衡量每个被检索到的文档块整体是否与问题相关——三个问题全部拿到1.00满分。如果发布门槛只看这个指标，三个答案都会通过。

但把每个文档块拆成单独事实再逐一检查必要性，fact级精度分别是0.59、0.53和0.09。第三个问题意味着检索到的材料中大约九成的具体事实与所问无关。chunk级精度只问'这段话是否切题'，不衡量'这段话里有多少内容真正有用'。

AWS工程团队在博客中用这个实测案例引出Agent DLC（Agent Development Lifecycle）框架的核心论点：传统单元测试和CI/CD对代理仍然必要，但三个特性使其不充分。第一，代理是非确定性的，相同输入可以产生不同输出和执行路径；第二，提示词、工具描述、检索设置或记忆配置的改动可以以文本审查无法察觉的方式改变行为；第三，模型端点、知识库和外部API可以独立于代码仓库发生变化并影响代理行为。

框架将开发活动组织为两个嵌套循环。内循环是：评分→检查路径→改一个变量→重新评估，在固定标准下改进代理。外循环是：定义→构建→评估→发布→观察→反馈，允许标准本身变化。作者举了一个容易混淆的例子：如果生产用户要求代理替家人查询信息，但没有任何标准覆盖这个场景，这是外循环问题——需要定义授权边界并补充示例，然后用内循环去满足更新后的标准。把两者搞混，团队会试图用提示词修改去填补一个缺失的标准。

回到病假证明那个案例。提示词修改后，绩效评估问题从0.83提升到0.87，fact级精度从0.59跳到0.85；但病假证明的groundedness从0.39降到0.31，fact级精度从0.09降到0.04——一个改动，两个相反结果。诊断指向知识覆盖缺口：语料库中根本没有专门的病假政策文档，只有休假管理政策中的简短提及。告诉模型'严格基于检索内容回答'无法凭空补充缺失信息。

评估标准被组织为五个维度——领域理解、质量、责任、成本、性能——和三个层级：硬约束（布尔值，违反即阻止发布）、发布门槛（k次运行的通过率阈值）、仅监控（追踪但不阻塞）。作者特别指出一个案例：福利登记答案以0.90的groundedness通过，但其中包含一句'我注意到你的档案显示你的首选联系方式是社交媒体'——不存在这样的档案。模型把政策文档中的一个选项与公共FAQ中一条无关回答拼合，包装成关于用户的事实。高分的groundedness没有捕捉到这个虚假个人声明。

框架的实际建议是：选一个明确范围的业务任务，用一周建立评估基线。前两天由业务负责人和工程师商定验收标准、层级和阈值，准备20到30个黄金示例。第三到五天实现评估器并反复运行黄金集，发布基线包括失败案例。第二周改一个变量、在相同条件下重新评估，记录发布决定及其证据。作者强调分数可在不同运行间波动，边界通过可能变成失败，应结合重复运行和底层证据来解读差异。

加拿大电商平台Shopify于2026年11月12日在其工程博客上披露了名为“Cyber Chaos Monkey”（CCM）的内部安全系统。该系统利用前沿AI模型，结合Shopify对自身软件架构、源代码和基础设施的深度知识，主动对生产环境发起模拟攻击，旨在在外部攻击者发现漏洞之前将其识别并修复。

CCM的核心逻辑是利用信息不对称优势。Shopify指出，随着前沿模型将漏洞发现的成本推向零，其Bug Bounty计划收到的报告数量自2024年以来增加了近300%，导致人工审核和处理变得极其困难。CCM通过向AI代理提供实时测试凭证和对系统的全面访问权限，使其能够像一名高级漏洞赏金猎人一样工作，但规模远超人类能力。

系统架构分为“Discovery”（发现）和“Sandbox”（沙箱）两个组件。Discovery负责接收假设或线索，利用最新网络模型细化潜在漏洞位置；Sandbox则执行具体的利用尝试，包括安装软件包、构建模糊测试工具以及直接向Shopify生产环境发送请求并分析日志。这种闭环允许AI代理根据反馈迭代优化攻击策略。

为确保安全性，Shopify实施了多层控制措施。技术层面，所有操作均在容器化环境中进行，遵循最小权限原则，并通过凭证代理和严格的出口白名单限制网络访问。治理层面，引入了“双人完整性”（Two-Person Integrity, TPI）机制，使用一个独立对齐的AI代理实时监控执行代理的行为日志。如果监控代理检测到违反“交战规则”（Rules of Engagement）的高风险行为，可立即终止任务。

据Shopify称，CCM已执行了数万次进攻性参与，识别并处理了数十项具有影响力的安全发现，且未造成任何服务中断或安全事故。这一实践标志着企业安全防御从被动响应向由AI驱动的主动、自动化红队测试的转变。