面向智能体的服务计算：服务计算下一前沿的宣言

# 面向服务计算下一个前沿的宣言
来源：https://arxiv.org/html/2607.12619
Amin Beheshti¹, Rong N. Chang², Boualem Benatallah³, Fabio Casati⁴, Schahram Dustdar⁵, Geoffrey Fox⁶, Quan Z. Sheng¹, Yan Wang¹, Jian Yang⁷, Albert Zomaya⁸

###### 摘要

由大语言模型驱动的自主与半自主智能体的迅速崛起，正将软件系统从静态的请求-响应组件重塑为以目标为导向、自适应的、能够使用工具的计算主体。随着这些智能体从孤立的认知原型走向复杂的分布式工作流，它们面临着服务计算社区二十多年来一直研究的挑战：组合、互操作性、服务质量、生命周期管理、治理、安全性和信任。然而，当今许多智能体 AI 生态系统正在临时构建这些基础，缺乏企业和社会可靠部署所需的工程严谨性。本文提出了**智能体面向服务计算 (Agentic Service-Oriented Computing, ASOC)** 作为一个新的研究和实践领域，其关注点在于：将智能体作为服务进行工程化，通过自主和半自主智能体编排服务，以及在信任、网络安全、合规性、性能和问责制的约束下治理智能体与服务的生态系统。我们阐述了 ASOC 的六项基本原则（可驾驭性、可组合性、生命周期工程、设计可信性、目标驱动编排、可观测性/问责制），并组织了一个五维研究议程，涵盖：(i) 智能体服务基础与生命周期工程；(ii) 组合、编排与互操作性；(iii) 治理、可观测性与问责制；(iv) 安全、信任与风险管理；(v) 评估、认证与智能体 QoS。我们认为，服务计算社区尤其具备条件，能够为这一新兴领域提供概念和工程核心，将智能体 AI 从零散的演示转变为值得人类和组织信赖的、可靠的服务型系统。

## I 转折点

软件系统正在经历一场与前几代变革性质不同的转型。之前的每一个范式（从意大利面条式代码和结构化编程，到面向对象设计，再到面向服务计算和微服务架构所实现的互操作性和可组合性）都通过引入新的抽象、模块化和可重用性层次来克服其前身的局限性 [5, 26, 1]。然而，这些转变都保留了一个基本常量：人类开发者仍然是显式计算逻辑的作者，将意图转化为机器执行的指令。现在，自然语言正成为一种用于指定目标、约束和期望结果的高级媒介，而智能体则越来越多地将这些规范转化为可执行的计划、服务调用和自适应工作流 [5]。这种转变不仅仅是技术升级；它改变了软件制品本身的本质。

基于 LLM 的智能体并非第一个自主软件实体。自主智能体、BDI（信念-愿望-意图）架构、多智能体系统、工作流智能体和自适应系统的研究已有数十年的历史 [16]。当前这一代智能体的独特之处在于更具体：基于 LLM 的智能体是第一个广泛可部署、以自然语言为媒介的软件实体类别，它们将推理、规划、工具使用、服务调用、记忆和自适应执行结合成一种可供主流企业和社会部署使用的形式。与传统的服务制品（通常使用完全指定的请求进行调用，并期望返回有界响应）不同，基于 LLM 的智能体可以接收一个未完全指定的目标，并自行决定如何实现它。它能感知上下文，在不完整规范下进行上下文敏感决策，选择和排序行动，将子任务委托给其他智能体或服务，从失败中恢复，并根据环境反馈动态调整。

这种转变在实践中已可见。基于 LLM 的智能体正被部署在企业工作流、科学发现流程、客户服务系统、软件工程流程和公共服务中。生态系统平台如 LangGraph¹¹¹https://www.ibm.com/think/topics/langgraph、CrewAI²²²https://crewai.com/、AutoGen³³³https://microsoft.github.io/autogen/stable//index.html、Microsoft Copilot Studio⁴⁴⁴https://www.microsoft.com/en-us/microsoft-365-copilot/、OpenAI 的 Codex⁵⁵⁵https://chatgpt.com/codex/ (Responses API/Agents SDK/AgentKit) 以及相关的智能体框架，为构建和部署智能体工作流提供了支撑；这些平台示例性地展示了快速发展的生态系统，并非详尽无遗的清单。模型上下文协议 (MCP) [3] 已成为将 LLM 应用与工具和外部数据源连接起来的开放协议，而智能体间协议 (A2A) [13] 则旨在支持跨企业平台的智能体间的通信、安全信息交换和协调。MCP 和 A2A 是重要早期信号，表明智能体生态正朝着互操作性发展，但它们本身并不能解决完整的**智能体面向服务计算 (ASOC)** 问题。ASOC 必须定义其周围的工程框架：能力契约、委托语义、生命周期管理、智能体 QoS、信任校准、合规性证据以及基于驾驭的治理。它们是脚手架，而非基础。

然而，在智能体能力令人印象深刻的表象之下，隐藏着一个深刻且日益扩大的工程赤字。当前的智能体系统在设计上普遍是临时的，在运行上治理薄弱，在决策上不透明，并且远不能达到企业和社会部署所需的安全性、合规性和可靠性要求。智能体通常被构建为孤立的认知原型。它们缺乏版本控制的接口、强制执行的 Service-Level Agreement、运行时监控、系统化故障恢复，以及使分布式系统值得依赖的互操作性契约。实际上，该领域正在重复 SOA 之前的分布式计算的错误：*在缺乏使大规模系统值得信赖所需的工程纪律的情况下，组装了令人印象深刻的功能。*

这正是面向服务计算社区必须采取行动的时刻。由智能体 AI 提出的问题（即，*在现实环境中如何设计、组合、编排、治理、监控和信任智能体*）本质上是面向服务计算的问题。它们正是我们社区自 2000 年代初的奠基性工作以来一直研究和解答的问题 [22, 25, 26]，只是现在在新的自主性和智能性层面上得以实现。从 Web 服务、服务生态系统和微服务到智能体服务的转变并非脱离我们的知识传统；而是其最雄心勃勃的表达。

本文既是学术论证，也是行动号召。本宣言做出四项贡献：

- • **第一**，它定义了**智能体面向服务计算 (ASOC)** 作为一个新兴的、根植于（但超越了）**面向服务计算 (SOC)** 的研究和实践领域。
- • **第二**，它通过**智能体即服务、由智能体编排的服务、以及受治理的智能体-服务生态系统**，引入了一个 ASOC 的三元框架。
- • **第三**，它阐述了用于可靠智能体服务的六项基础工程原则。
- • **第四**，它提出了一个五维研究议程，涵盖生命周期工程、组合、编排、治理、网络安全、信任和评估。

本文的其余部分组织如下。第二节回顾了面向服务计算的传承，并确定了 ASOC 继承并改造的七项基础支柱。第三节考察了基于 LLM 的智能体 AI 的兴起，描述了其认知能力，并通过四个特定领域用例说明了其利害关系。第四节正式定义了智能体服务计算，引入了四个核心技术概念（智能体服务、委托契约、智能体驾驭、智能体服务生态系统），提出了 ASOC 参考架构，并将 ASOC 定位于相邻研究领域。第五节阐述了 ASOC 的六项基础工程原则，每项都附有定义、动机、核心研究问题和具体实现机制。第六节提出了五维 ASOC 研究议程，涵盖：智能体服务基础与生命周期工程；组合、编排与互操作性；治理、可观测性与问责制；安全、信任与风险管理；以及评估、认证与智能体 QoS。第七节论证了服务计算社区在该领域的领导地位。第八节以对研究和实践社区的号召结束。

## II 面向服务计算 (SOC) 的传承

服务计算社区花费了二十多年的时间，正是为了解决智能体 AI 现在面临的工程问题。本节阐述 ASOC 所继承的内容。面向服务计算的七个基础概念直接适用于智能体上下文，每一个都变得更难实现，但同样不可或缺。

### II-A ASOC 继承的 SOC 七支柱

**表 I：从 SOC 到 ASOC：面向服务计算基础支柱向概率性、目标导向的智能体服务的转变。**
**服务契约和接口。** Papazoglou 和 Georgakopoulos 确立了每个 SOC 交互都建立在明确定义、发布的服务契约之上 [22]。Papazoglou 的综合教材 [26] 仍是这些原则的权威论述。扩展的面向服务架构 [25] 引入了由基础服务、复合服务和受管服务组成的分层金字塔，确立了成熟的服务基础设施是一个受治理的生态系统。在 ASOC 中，服务契约必须扩展以描述目标类型、不确定性特征、执行约束和信任要求。

**发现与绑定。** 发布-发现-绑定模型 [22] 确立了服务必须能被未参与其设计的主体发现。在 ASOC 中，发现必须在目标层面进行：编排智能体必须能够发现、评估并绑定到能力与指定目标相匹配的智能体服务，而不仅仅是与类型化接口相匹配。

**组合与编排。** 服务组合是早期 SOC 定义性的研究挑战。Casati 等人的 eFlow [8] 展示了自适应、运行时可修改的组合。Self-SERV [7] 引入了声明式、对等模式的服务供应。BPEL4WS [2] 提供了一种可执行流程表示法。McIlraith 和 Son 将 AI 规划引入了语义组合 [18]。Dustdar 和 Schreiner [10] 以及 Lemos、Daniel 和 Benatallah [17] 的综述描绘了从手动到全自动方法的全景。上下文感知规范技术，如 ContextUML [29]，预示了智能体服务所需的更丰富的能力描述。在 ASOC 中，组合必须在目标层面进行，由智能体而非静态工作流引擎作为组合者。

**服务质量与 SLA。** Zeng 等人 [35] 论证了服务选择必须优化复合的非功能属性，包括延迟、可靠性、成本和可用性。这一见解（即工程必须考虑组合系统涌现的 QoS 属性）仍然是 SOC 社区最重要的贡献之一，但在当前的智能体 AI 工程中几乎完全缺失。

**生命周期工程。** SODDM [24] 建立了一个正式的服务生命周期：分析、设计、实现、测试、部署、管理和演进。在 ASOC 中，这个生命周期必须扩展以适应其行为受底层模型影响的概率性、目标导向的智能体。

**治理与信任。** Papazoglou 和 van den Heuvel 论证了治理在服务系统中是不可选的 [27]。2008 年的 SOC 研究路线图 [23] 将其正式化为四个主题：基础、组合、管理和监控、以及工程。

**监控、可观测性与审计性。** 从服务交互日志中推导协议模型的工作 [20] 确立了服务行为必须在运行时被观察和分析的原则。在 ASOC 中，由于智能体推理是概率性的且内部不透明，可观测性和审计性更为关键，技术上也更难实现。表 I 总结了在 ASOC 背景下，SOC 的七项支柱分别如何转变。对于每个继承的概念，该表展示了 SOC 社区构建了什么，以及 ASOC 现在必须扩展、强化或重构什么，以处理概率性、目标导向的智能体行为。

### II-B 从 Web 服务到云和微服务

SOC 传统随着技术变革稳步演进。Fielding 的 REST [11] 使得 LLM 工具调用现在所依赖的 API 经济成为可能。微服务运动 [12] 将服务单体分解为独立可部署的有界服务，预见了服务边界处的认知能力。NIST 云模型 [19] 完善了 *即服务* 的抽象。基于智能体的软件工程 [16] 的知识遗产构成了重要的前身，特别是在动态环境中设计自主、目标导向的实体方面。经过二十五年的研究，SOC 社区构建并验证了工程原则（契约、可发现性、可组合性、QoS、生命周期、治理和可观测性），这些原则现在正等待着在智能体语境下重新确立。

## III 智能体 AI 的崛起：承诺与风险

### III-A 基于 LLM 的智能体：它们能做什么

大语言模型作为软件智能体认知核心的出现，代表了能力上的一个根本性转折点。基于 LLM 的智能体将自然语言理解与推理、规划和工具调用相结合，使得