Linux Foundation Agent Name Service 为 AI 代理提供什么身份能力

Agent Name Service（ANS）为 AI 代理提供与域名关联的命名、可发现的身份材料以及通信对端的身份验证框架。它把“这个代理叫什么”“身份记录是否有效”“当前调用方是否持有对应密钥”联系起来，帮助跨平台系统确认正在与谁通信。具体能访问哪个业务资源、能执行什么操作，仍由接收请求的应用决定。

假设企业采购代理要调用供应商的库存代理。一个相似的名称、一张公开展示的标识，甚至一个可访问的接口，都不足以单独说明当前请求来自预期代理。ANS 试图补上可验证的身份关系；库存接口的读取、预留和修改权限，则是接入后仍然要处理的问题。

项目官方地址：https://ansinfo.ai/

官方代码组织：https://github.com/agentnameservice

项目落地以后，哪些事情已经明确

Linux Foundation 在 2026 年 11 月 10 日宣布 ANS 作为基金会项目推出。公告介绍了基于 DNS 的代理身份与发现机制，并提到 AGNTCY 的 Agent Directory Service 支持 ANS 身份验证，以及 ANS Finder 与 ARD 的互操作进展。这些是已公布的项目与集成信号，不等于所有代理平台已经兼容。

这里有一个需要区分的状态：项目已经进入基金会治理，而项目网站仍明确说明公开规范是持续开发中的草案。前者说明治理与协作归属，后者提醒实现者要固定依赖版本、关注契约变化。不能把“项目正式推出”直接写成“协议永不变化”或“已经成为最终互联网标准”。

官方公告：https://www.linuxfoundation.org/press/linux-foundation-welcomes-agent-name-service-to-bring-verifiable-identity-and-discovery-to-ai-agents。规范入口：https://ansinfo.ai/docs/。

名称、证书与记录各自证明什么

理解 ANS 可以先区分三类对象：名称提供明确的身份指代；证书及相关证明帮助建立密钥与身份的关联；注册状态和透明记录让身份的生命周期具有可检查的材料。它们回答的问题不同，不能互相替代。

项目说明将身份、当前状态和密钥持有情况作为验证的不同部分。公开的身份标识或收据可以被别人读取，因此展示材料与当前调用者的认证不能画等号。验证端还要使用可信的密钥和正确的校验过程，并处理状态的新鲜度。

同样，记录完整性与运行行为是两种结论。项目文档指出，已封存的元数据摘要可以绑定发布材料，但不证明远端机器实际执行的代码，也不保证代理行为。企业不能因此撤掉原有的应用监控、访问日志或业务约束。机制说明：https://ansinfo.ai/how-it-works/。

身份可信以后，业务权限仍需单独决定

回到库存代理场景。即使采购代理的身份验证通过，库存系统仍需要知道它要读取哪个租户的库存、是否可以预留商品，以及调用是否代表某个用户的授权。下面是本文建议的业务侧拆分，不是 ANS 规范增加的字段。

1. 保存已验证身份及验证结果，避免后续组件重新相信请求里任意自报的代理名称。
2. 把具体操作和目标资源交给本地授权策略。例如，库存查询与库存扣减分别决策。
3. 将允许或拒绝的结果关联到审计记录，记录必要上下文；不要把私钥、访问令牌写入日志。

这样划分后，身份验证失败与权限不足可以分别处理。前者需要处理认证材料、状态或信任配置；后者需要检查本地策略及调用范围。若系统将两者都概括成“代理不可信”，运维人员就难以判断应联系证书管理者还是业务权限负责人。

开发团队如何安排一个小范围试用

对于已有固定合作方、需要跨平台代理通信的团队，小范围试用比立即替换整个身份系统更容易评估。本文建议选择只读、低影响的测试接口，先建立一对代理的预期身份与允许操作，不把生产数据或高权限令牌直接交给演示环境。

项目开发者入口给出参考实现、CLI、SDK 与网关集成等路径。它们的覆盖范围和 API 不完全相同，选用前应阅读相应仓库的版本说明。参考实现用于理解注册与证明材料如何组合，不代表每种 SDK、每种发现机制都具有同等实现程度。

开发者指南还明确提醒，默认本地演示使用开发密钥和 noop DNS 验证器；演示中的收据校验成功不等于公网 DNS、生产证书签发或真实部署已经通过验证。因此，试用记录应分开写“本地流程已理解”和“实际环境已覆盖哪些条件”。

实际接入还应明确注册机构、透明日志端点、信任哪些日志密钥，以及证书轮换与注册撤销由谁负责。不要仅因为发现了一个名字就自动加入可信集合，也不要让验证材料不可用时悄悄变成全部放行。开发者入口：https://ansinfo.ai/for-developers/。

判断能否采用，要观察哪些结果

新闻中的组织参与和集成案例说明生态正在推进；对具体团队而言，更有意义的是下面这些可记录的采用结果。这些指标属于本文建议，没有在本文中进行实测。

如果团队当前只有单一平台内的固定工具调用，已有身份机制能够满足需求，可以先跟踪规范和实现进展。若主要困难已经变成跨组织发现代理、共享可验证身份材料和管理身份变更，ANS 才更值得进入专项试用。是否采用，应由实际互操作需求和运维成本决定。

常见问题

ANS 是否会替企业决定代理的业务权限？

不会。身份验证提供决策输入；具体动作和资源是否允许，仍需要应用自己的授权策略。

知道代理域名就能信任它吗？

不能。域名与名称只是身份关联的一部分，还要处理凭据、状态、持钥证明及本地信任配置。

透明记录能保证代理输出正确吗？

不能。它关注登记材料和可审计记录，不保证模型输出、远端执行代码或业务行为始终正确。

加入 Linux Foundation 就代表规范已经定稿吗？

不能这样理解。项目网站仍将公开规范标为持续开发的草案，实施时需要记录版本与覆盖范围。