2026年9月17日至23日的四项进展显示，智能体技术栈正不断扩展，不再局限于模型：还包括访问控制、安全检查，以及衡量智能体实际行为的方式。
本文涵盖的时间段为2026年9月17日至9月23日，首尾日期均包括在内。在这段时间里，有四项与开发者和自动化工作流构建团队尤为相关的公告。它们的共同主题很务实：随着 AI 系统承担更长或影响更重大的任务，周边基础设施——谁能访问、如何检查操作，以及一次变更是否会降低性能——与模型能力同样重要。
9月17日：Anthropic 为生命科学团队推出验证计划
Anthropic 推出了生命科学验证计划，为经过验证的生命科学机构提供 Mythos、Opus 和 Sonnet 模型的访问权限，并采取该公司称对生物学相关工作限制更少的安全措施。该计划目前处于测试阶段，最初面向团队和机构。申请者将根据研究资质、安全标准和伦理监督情况接受评估；获批团队可以申请不同级别的访问权限。该计划可通过 Claude 产品和 API 使用。（anthropic.com）
为何重要：这是一个具体例子，说明访问权限会根据组织申明的用途和控制措施来设定，而不只是取决于用户选择哪种模型。对于构建专业 AI 工作流的开发者来说，设计问题不止是“模型能做到这件事吗？”，还包括“谁有权使用它、需要经过怎样的审核，以及由谁监督？”
Anthropic 还指出了访问权限遭到滥用，以及以群体协作方式或在长时间任务中运行的智能体采取非预期操作等风险。因此，该计划的意义不只限于生命科学：它展现了当 API 调用成为能够执行多个步骤的系统一部分时所面临的治理难题。公告介绍了该计划的做法，但并未证明这些安全措施在大规模应用时会有多大成效。（anthropic.com）
9月18日：Google 介绍持续运行、由智能体辅助的安全扫描
Google 的基础设施团队介绍了一种在代码提交前使用 AI 智能体审查代码变更的方法，而非只依赖大规模、定期开展的安全扫描。根据其系统介绍，扫描器会利用实时代码库元数据和依赖调用图，构建更有针对性的威胁背景信息。Google 表示，其系统每月可阻止数百个漏洞进入代码库或生产环境，并称在某些情况下误报率降至3%。这些是公司自行报告的结果，并非独立审计结论。（cloud.google.com）
实际启示与其说是照搬 Google 的规模，不如说是要考虑何时、何处运行检查。逐项审查代码变更，可以让安全工具获得比一次性扫描整个庞大系统更有针对性的背景信息。Google 表示，它为此改进了开源 Mantis 审查框架，并将威胁模型和多智能体框架列为其方案的组成部分。考虑采用类似工作流的团队，应将这些报告结果视为案例研究，而非性能保证：能否发现有价值的问题且不拖慢开发，取决于团队自己的代码库、威胁模型和审查流程。（cloud.google.com）
9月22日：AWS 推出 AI 智能体可观测性工作流
AWS 宣布推出CloudWatch Omni，用于观察、评估和试验智能体工作负载。AWS 表示，团队可以检查追踪记录、比较提示词版本、根据生产流量构建测试数据集，并针对不同配置运行实验。它为开发者提供 VS Code 和 Kiro 扩展，并为运维人员提供独立的 Web 界面。（aws.amazon.com）
这项工具针对的是传统运行时间仪表板可能忽略的问题：工作流即使返回了成功响应，在提示词、模型或工具发生变更后，实际效用仍可能下降。AWS 列出了针对正确性、连贯性、检索质量和工具选择等方面的内置评估器。对工程团队而言，重要的转变是像对待软件变更一样对待智能体变更：记录运行情况，定义针对具体任务的检查，并在扩大部署范围之前查找性能退化。
发布说明并未证明这些评估器能满足所有团队的需求。通用的正确性分数不能替代特定领域的测试；仅有追踪记录也不能说明智能体的操作是否恰当。团队仍需自行确定其特定工作流的成功标准。（aws.amazon.com）
9月22日：Anthropic 宣传 Opus 5.5 的能力与成本优势
Anthropic 宣布推出Claude Opus 5.5，并称该模型在大多数工作任务上的表现可与 Claude Fable 5.1 相当，运行成本却比 Opus 5 低40%。该公司表示，这款模型可通过其平台及多家云服务提供商使用，开发者也可以通过 Claude API 访问。上述性能比较和成本说法均来自 Anthropic；团队应结合自己的实际工作负载进行测试，而不应将其视为必然节省。（anthropic.com）
对于智能体构建者而言，每次运行的成本只是计算的一部分。有意义的比较还应包括任务成功率、延迟、重试次数、工具调用次数，以及所需的人工纠正量。每个 token 成本较低的模型，如果需要更多步骤或会造成更多可补救的错误，未必能降低工作流的总体成本。这项公告提供了对比测试其他选项的理由，但并不意味着无需评估就应切换生产流量。
要点：智能体技术栈正成为运维问题
这些公告涉及不同层面：专业工作所需的受控访问、代码审查安全、智能体可观测性，以及模型经济性。综合来看，它们为构建者指出了一项务实的优先任务：在提高自主性之前，让智能体的行为可检查、可测试。应谨慎设置权限，记录工具使用情况，评估有代表性的任务，并将模型变更与基线进行比较。
这些方案在不同独立工作负载中的表现如何，仍不确定。产品发布公告和厂商报告的结果是有用的参考信号，但无法替代团队自己的测试。开发者下一步该做什么很明确：将每个智能体工作流都视为一个有可衡量结果的系统，而不是仅仅因为提示词生成了看似合理的回答，就认为它值得信任。