AI Agents 正在进入其微服务时代，但这一类比存在局限

StartupHub.ai 通过 Google News 提出了一个尖锐观点：AI agents 如今所处的位置，正如微服务在 2015 年所处的位置。尽管 agents 是否足够可靠、能够支撑这种架构仍存在未解问题，这一比较预示着基础设施转型正在逼近。

这是一种类比，而非产品发布或经过独立衡量的里程碑。它的价值在于揭示了其中的矛盾。AI 公司日益将 agents 描绘为模块化工作单元，能够使用工具、交换任务，并在业务系统间运行。

但 agents 并非普通的软件服务。它们会解读含糊的语言、生成不固定的输出，有时还会采取设计者未曾预料的行动。连接更多 agents 可能会放大这些不确定性，而非将其控制住。

微服务也经历过艰难转型。团队获得了独立部署与扩展能力，随后却面临服务发现、追踪、身份验证、延迟和分布式故障等新问题。围绕这些运营缺口，形成了一个基础设施产品产业。

AI agent 市场如今似乎正沿着这一路径前行。Model Context Protocol，即 MCP 等标准，将 AI 应用与工具和数据连接起来。被称为 A2A 的 Agent2Agent 支持独立 agents 之间的通信与任务委派。

这种相似性使 StartupHub.ai 的框架具有参考价值，但并不意味着结果必然如此。决定性的竞争，在于模块化 agent 系统与使其值得信赖所需的运营控制之间的较量。

Google News 上的这一说法实际改变了什么

StartupHub.ai 的标题为 agent 市场设定了比又一次关于自主软件的预测更严苛的标尺。

该文章以“AI Agents Are Where Microservices Were in 2015”为题，通过 Google News 出现。这个标题并未证明某项发生在特定时间的技术成就，而是提出了行业发展曲线上的一种定位。

这一比较指向 2015 年，是因为微服务当时正获得广泛关注，但支撑它们的基础设施仍不完善。许多组织在理解其架构前景之前，尚未理解其运营成本。

微服务将应用拆分为可独立部署、具有明确接口的服务。这种方式让团队能更自由地更新、扩展和替换各个组件。

但它也将复杂性从代码库转移到了网络中。一次函数调用变成了一项远程请求，可能超时、失败、重试，或返回不兼容的响应。

agent 版本看起来很熟悉。一家公司可以将研究、规划、编码、客户支持或采购拆分给专门的 agents。编排器可以分派工作，而每个 agent 使用不同的模型、工具、数据或权限。

Microsoft 的 agent architecture 直接记录了这种模式。它将 agents 描述为通过定义明确的 API 或消息协议连接起来的独立服务。

同一份参考资料也指出了其中的权衡。agent 间通信会增加延迟和故障模式；共享上下文更难管理，而治理和安全机制必须跨越服务边界。

这些警示之所以重要，是因为 AI agent 不只是传统 API 包装器。它会根据模型生成的推理、检索到的上下文、工具描述和用户指令来选择行动。

正常服务在收到有效请求时应表现得可预测。agent 则可能在模型更新、上下文变化或工具响应变化后，以不同方式理解同一目标。

这种差异改变了该类比所要求的内容。agent 构建者不仅需要服务发现、路由和负载均衡的对应机制，还需要能够记录意图、任务委派、证据、权限和生成决策的系统。

因此，Google News 的标题将注意力从模型智能转向运营成熟度。相关问题不再是 agent 能否完成一次令人印象深刻的演示。

问题在于，团队能否部署大量 agents 而不失去可见性或控制力。这一标准对 agent 平台、云服务提供商、安全厂商和企业工程团队构成了压力。

这也解释了为什么基础设施成为讨论的中心。下一阶段更少取决于又一个打磨精致的助手，更多取决于不确定组件之间可靠的契约。

为什么 AI Agent 基础设施正在趋于融合

随着开发者开始将工具访问、agent 通信、身份和编排拆分为不同层次，agent 基础设施正在形成。

早期的 agent 演示通常将所有功能捆绑在一个应用中。单一进程包含提示词、模型选择、工具定义、记忆、执行循环和用户界面。

这种设计适用于实验，因为开发者可以检查一个代码库并同步更改所有层次。当多个团队、模型、供应商或安全域进入工作流时，它就会变得脆弱。

MCP 解决了这一问题的一部分。该协议为 AI 应用提供了发现和调用工具或检索上下文资源的共享方式。

A2A 则解决了另一层问题。A2A specification 描述了一项标准，独立 agents 可借此发现能力、交换任务并传达结果。

这种区分很重要。agent 与数据库之间的连接，不同于拥有不同所有者和内部推理过程的两个 agents 之间的任务委派。

这种划分类似于围绕分布式软件形成的分层。开发者最终将应用逻辑与网络、服务发现、遥测、策略和部署管理分离开来。

近期的治理活动强化了这一比较。Axios 在 2026 年 8 月报道称，Google 的 A2A 项目正转入 Agentic AI Foundation。

根据这份标准报告，该基金会的成员已从不足 40 家增长至超过 250 家。参与者包括主要的云服务、模型、软件和商业公司。

这一举措将 A2A 与 MCP 及相关项目置于更聚焦的治理架构之下。它并不保证互操作性，但表明多家供应商已认识到协调问题。

中立治理可以减少一种犹豫来源。企业通常不愿意让重要工作流被锁定在某个模型提供商的内部 agent 格式中。

通用接口提供了另一种选择。采购 agent 可以将合同分析委派给一家提供商，将合规审查委派给另一家，并将内部数据检索交由公司自主管理的服务。

这种模块化让买方拥有议价能力和技术灵活性，但也增加了身份、上下文和权限可能失效的边界。

这正是微服务类比为何此刻出现的原因。agent 能力已进步到足以让集成问题显现，而标准仍足够年轻，尚在竞争采用。

时机同样受模型多样性的影响。公司越来越多地针对推理质量、延迟、隐私、多模态能力或运营成本选择不同模型。

单一的单体 agent 可以通过一个接口隐藏这种选择。多 agent 系统则会暴露这些差异，并要求组件间建立明确契约。

开发者还需要持久的组织上下文。如果 agent 缺少请求背后的文件、决策、术语和历史记录，它就无法完成有价值的工作。

这一要求提升了检索和 knowledge blending 的重要性。不过，更好的上下文并不能消除访问控制或来源追踪的需求。

基础设施层必须同时回答几个问题：哪个 agent 接收了任务，它读取了哪些数据，它调用了哪些工具，以及谁批准了该行动？

微服务平台最终让有关服务和网络请求的类似问题成为常规。agent 系统仍通过碎片化日志、框架专属追踪和应用代码来回答这些问题。

这一缺口造就了 StartupHub.ai 说法背后的机会，也揭示了市场距离稳定基础设施层仍有多远。

模块化 Agents 面临同样的分布式系统代价

将一个 AI 工作流拆分为多个 agents 可以提高专业化程度，但也会将局部不确定性转化为分布式不确定性。

微服务承诺独立所有权和部署能力。这些优势确实存在，尤其适用于拥有众多团队且扩展需求不均衡的大型组织。

其成本同样真实存在。服务需要稳定的契约、版本控制、发现机制、重试、身份验证、分布式追踪，以及处理部分故障的机制。

agents 继承了上述所有需求，还增加了概率性行为、不断变化的模型输出、提示词注入、上下文限制和模糊的任务委派。

以客户支持工作流为例。一个 agent 对请求进行分类，另一个检索账户数据，再由另一个提出解决方案。

第四个 agent 可能在收到批准后处理退款。每次交接都会携带前一步的数据、假设和权限。

如果检索 agent 选择了过时的政策，解决方案 agent 可能会给出自信但无效的建议。退款 agent 随后可能依据该建议执行操作。

故障并不局限于某一个组件，而是在整个链条中出现，这使传统调试的效果变得有限。

显示网络请求成功的追踪记录，无法解释 agent 是否误解了一项政策。模型转录记录也无法证明其获得了访问正确客户记录的授权。

因此，agent 可观测性需要多个层次。团队需要网络遥测、模型输入、工具调用、检索来源、决策路径和审批事件。

系统还必须在保留有用记录的同时，避免存储不必要的私人信息。详细追踪本身也可能成为安全和合规风险。

重试展示了另一种差异。传统服务通常可以重复幂等操作，这意味着同一请求不会产生额外影响。

agent 重试可能生成不同的计划或选择另一种工具。重复失败的采购请求可能创建第二笔订单，除非周边系统实施事务控制。

状态则带来更多困难。一个 agent 可能存储摘要，另一个则保留原始文档。随着任一表示形式发生变化，它们的结论可能逐渐偏离。

微服务针对类似问题的应对措施包括明确的模式、契约测试、事件日志和分布式状态管理。agent 平台需要能将模型行为纳入考量的对应机制。

agent 身份是另一项缺失的控制措施。服务通常在定义明确、权限受限的工作负载身份下运行。

一个 agent 可以将任务委派给另一个 agent，后者还可能继续委派。每次传递都会引出一个问题：权限是否应随任务一同转移。

最安全的答案很少是无限继承。获准读取客户记录的研究代理，不应自动将该权限授予外部规划代理。

短期凭证、限定范围的访问权限和明确的委托记录可以限制暴露面。然而，仅靠协议无法落实组织的政策。

模块化架构也改变了采购方式。企业可以从多家供应商组装代理，同时将编排和敏感数据保留在自身环境中。

这种安排避免由单一提供商掌控整个工作流，同时也让事故责任更难界定。

故障是由模型、提示词、工具连接器、编排器、数据源，还是接收代理造成的？每家供应商都可以提出技术上看似合理的辩护。

这一问责问题使代理基础设施区别于普通的组件集成。系统需要保留足够证据，不仅重建发生了什么，还要说明为何授予了权限。

2015 年的类比在这里依然最有说服力。微服务之所以变得实用，是因为组织将运维工具视为架构的一部分，而非可有可无的附加项。

代理也需要同样的转变。能完成任务的演示只是开始。真正的生产就绪始于系统能够遏制、解释并从故障中恢复。

真正的问题是行为，而非连通性

共享协议可以连接代理，但无法让它们的决策变得正确、安全或一致。

互操作性是重要的工程目标。它减少了定制集成工作，也让开发者能够替换组件，而无需重建整个工作流。

但成功交换消息只是对成功的狭义定义。两个代理可以完美通信，却传递不准确的假设、不安全的指令或过度授权。

这一局限削弱了微服务类比最简单的版本。传统服务实现的是工程师可以检查、测试和约束的代码路径。

代理使用的模型，其输出会随提示词、上下文顺序、检索材料、工具描述和采样行为而变化。即使采用确定性设置，也无法消除模糊任务带来的不确定性。

代理即使未被攻破，也可能出现错误行为。它可能遵循合法指令、使用获授权的工具，却依然做出有害的选择。

这种风险不同于常见的入侵模型。为阻止未授权访问而设计的安全控制，并不一定能阻止已获授权但判断失误的行动。

NIST 在 2026 年 5 月发布的代理安全分析体现了这一担忧。受访者普遍认为，新型代理安全威胁是阻碍采用的因素。

该机构还发现，各方普遍认同既有网络安全实践依然适用。不过，这些实践需要针对代理系统进行调整。

这是基础设施热情往往忽略的审慎视角。在可靠性改善之前，更好的路由和标准化可能会增加代理能够触及的系统数量。

通用工具协议可以降低安全应用的集成成本。同一协议也可能扩大遭操纵或陷入混乱的代理所造成的后果。

提示词注入说明了这种冲突。代理可能检索到一份包含旨在重定向其行为的文本的文档。

如果代理将该内容视为指令，就可能违背用户意图泄露信息或调用工具。事件发生期间，网络连接可能始终保持正确认证。

多代理系统扩大了攻击面，因为不可信内容可以在组件之间传播。一个代理可能将恶意文本转换成看似可信的摘要。

接收代理随后便缺少识别操纵所需的原始上下文。委托可能通过原本有效的工作流，将高风险指令“洗白”。

开发者需要明确边界，以区分数据、指令、政策和用户批准。这些区分必须在每一次消息传递和转换中得以保留。

他们还需要测试完整工作流的评估方法，而不只是测试单个模型响应。规划代理可能通过孤立测试，却会在另一个代理提供不完整上下文时失败。

长时间运行的任务还会带来另一种不确定性。持续运行数小时的代理会遇到变化的文件、凭证、网络条件和业务状态。

其原始计划可能在执行结束前就已失效。系统必须检测这种变化，并请求确认，而非基于过时假设继续执行。

人工批准提供了一种控制手段，但批准设计很重要。含糊地询问是否“继续”的提示，几乎不给审核者作出判断的依据。

有用的批准应说明预期行动、受影响资源、证据、范围以及可逆后果。高影响行动需要比只读检索更严格的确认。

企业还必须决定哪些场景适合自主执行。起草内部摘要的代理，与发送付款或修改生产基础设施的代理，风险截然不同。

这种差异倾向于渐进式部署。团队可以从只读任务、可衡量的输出和清晰的升级路径开始。

只有在收集到有关故障率和恢复能力的证据后，才增加执行权限。这一过程更像渐进式服务拆分，而不是立即迁移到自主代理网络。

市场仍可能形成类似服务网格的代理等价物。它可能围绕代理交互管理身份、政策、路由、遥测和标准化控制。

然而，它无法取代应用层面的判断。没有任何基础设施层能够决定每个组织可接受的错误率或批准边界。

因此，连通性不应被误认为成熟度。代理市场已开始标准化通信，却尚未标准化可靠行为。

随着技术栈成熟，谁将承受压力

新兴技术栈会因不同原因给封闭代理平台、企业买家和基础设施供应商带来压力。

封闭平台面临来自开放接口的压力。如果企业能通过共享协议连接模型、工具和代理，它们就拥有更大自由度来替换单个供应商。

供应商仍可以通过模型质量、安全性、托管或专业应用实现差异化。但仅靠专有连接器来捍卫平台将变得更加困难。

云服务提供商面临另一项挑战。它们希望提供首选控制平面，同时又不显得将客户困在单一模型或框架中。

支持开放协议可以缓解这一担忧，也可能削弱提供商对应用层的控制。

代理框架开发者必须决定哪些职责应归属其库中。仅靠提示词编排正变得不足以支持生产使用。

客户日益需要评估、追踪、政策执行、凭证处理、恢复和版本管理。将所有功能都加入，会让轻量级框架变成复杂平台。

可观测性公司获得了机会，但代理追踪需要不熟悉的数据。Token 数量和延迟无法解释某项委托决策是否合理。

有用的系统必须将技术事件与业务含义关联起来。它应展示哪些证据支持了某项行动，以及哪项政策授权了它。

安全供应商也面临同样的扩展。网络控制和身份系统仍然必要，但代理会在有效会话内带来决策风险。

供应商必须监控工具使用、委托链、上下文数据和不断变化的意图。过度监控可能暴露敏感提示词和文档，因此数据收集需要克制。

企业买家承担着最直接的负担。采用协议并不会自动形成运营模式、问责结构或可接受风险政策。

团队需要为代理身份、工具权限、数据源、评估、事件和批准规则明确负责人。这些职责往往横跨工程、安全、法务和业务部门。

知识管理也成为运营基础设施。当文档分散、权威性、时效性和归属不明确时，代理无法可靠工作。

可搜索的技术知识库可以改善检索。团队仍需为相互冲突的来源和过时指导制定政策。

构建代理基础设施的初创公司面临时机问题。客户已经意识到痛点，但标准和架构选择仍未稳定。

围绕某一协议构建可以加速当下的采用。如果治理、传输或安全要求发生变化，也可能带来迁移工作。

微服务市场曾出现许多工具，后来随着云平台吸收其功能而消失。代理初创公司面临类似风险。

有些类别将发展为独立业务。另一些则会成为云服务、模型平台、开发者工具或既有安全产品中的功能。

因此，这一类比更应指导架构，而不是提供投资确定性。它指出了运营压力积累之处，却无法预测哪些供应商能够捕获这些价值。

最具可辩护性的产品，可能会解决跨模型和框架持续存在的问题。身份、评估、可观测性、政策和可靠执行都符合这一描述。

即使这些类别之间也仍然相互关联。评估系统需要追踪数据，而政策引擎需要身份和上下文信息。

技术栈可能围绕共享事件格式和治理控制进行整合。另一种可能是，大型平台提供集成系统，并在边缘配备适配器。

两种结果都保留了核心冲突。买家希望拥有模块化选择，但也希望在工作流失败时有一方承担责任。

微服务从未消除这种张力。组织需要在独立组件与运营分布式系统的成本之间取得平衡。

AI 代理加剧了这种平衡问题，因为这些组件不只是会故障。它们可能在技术上看似健康的情况下，完成错误的任务。

Google News 读者接下来应关注什么

三个信号将表明，AI 代理是在重演微服务的高效发展阶段，还是仅仅重演其复杂性。

第一个信号是真正的跨供应商互操作性。当企业能够替换一个代理或模型，而无需重写周边工作流时，协议才真正重要。

同一基金会旗下项目之间的演示并不足够。买家需要独立实现，且能够保留任务状态、身份、权限和错误处理。

A2A 转向更聚焦的开放治理，加强了互操作性的理由。下一项考验在于，竞争平台能否在基础消息交换之外实现兼容行为。

关注一致性测试、共享能力描述和公开兼容性结果。这些进展将强化 StartupHub.ai 的类比。

持续存在的供应商专属扩展会削弱这一类比。它们将表明，协议只是通用封装，而有意义的行为仍然是专有的。

第二个信号是可衡量的生产可靠性。代理供应商经常展示在有限评估中的任务完成率，但企业需要工作流层面的证据。

有用的指标包括错误工具调用、未授权行动尝试、恢复成功率、批准频率，以及由过时上下文导致的故障。

这些措施必须反映真实环境，而不是经过精心挑选的演示场景。它们还应区分模型错误与集成、数据、权限和编排故障。

明确的生产指标将加强其与成熟分布式软件的比较。持续依赖轶事式成功案例则会削弱这一比较。

第三个信号是实用的身份与授权基础设施。智能体需要可验证的身份、范围受限的凭据，以及能够跨组织边界运作的委派记录。

NIST 已将智能体身份与安全纳入其标准议程。其标准倡议反映出业界对自愿性指导和行业协作日益增长的兴趣。

关键检验在于，这些努力能否产出可部署的模式。企业需要能够适配现有身份系统、并保持最小权限访问的控制机制。

最小权限是指仅授予完成特定任务所需的权限。当智能体改变计划或动态委派工作时，实现这一点会变得更加困难。

实用的系统应随着任务在链路中流转而收紧权限范围。它不应将宽泛的用户权限复制给每一个参与的智能体。

在这一问题上的进展，将加强智能体基础设施正进入持久平台阶段的论点。持续依赖共享 API 密钥则会削弱这一论点。

读者也应谨慎看待未来的 Google News 标题。“AI agent”一词如今涵盖助手、脚本化工作流、编程工具，以及具有实质自主性的系统。

这些产品承载着不同风险，不应被赋予同一种成熟度判断。一款可靠的起草助手，并不能证明自主金融或运营智能体已准备就绪。

StartupHub.ai 的标题之所以成功，是因为它为行业提供了有用的历史参照。若读者将这种比较解读为结果已经到来的证据，它就失败了。

2015 年的微服务提供了一种可识别的架构，但其运营模式尚未完成。如今的 AI 智能体呈现出同样的总体模式，但承担着更大的行为负担。

基础设施机会是真实存在的。同样真实的，还有将不可靠决策分散到更多工具、数据和组织之中的风险。

开发者应当问：每一条智能体边界是否都具备清晰的契约、身份、追踪记录、回退机制和责任人。企业采购方应在扩大权限前，要求看到完整工作流的证据。

知识工作者应关注智能体能够访问什么，以及哪些操作需要审批。便利性不应抹去准备工作与实际执行之间的差异。

最有力的确认不会是又一次雄心勃勃的智能体演示。它将是一个平淡无奇的生产系统：能够清晰暴露故障、限制损害，并可预测地恢复。

这才是 Google News 读者应追踪的里程碑。在它到来之前，微服务类比仍是一张有用的地图，而非抵达目的地的证明。