摘要

  • Uniform Resource Agent 把高层活动封装成一个包含激活数据、目标、经验信息、活动脚本和响应过滤器的持久对象，因而可以交给别人修改并重跑。
  • 真正执行对象的是 URAgency：它负责把对象类型映射到具体实现，补齐运行依赖，激活本地或远程目标，并解释返回内容。
  • 因此，规范被保存、对象可携带或程序成功启动，都不能单独证明输入获得授权、目标没有漂移、解释正确、结果可复现或任务已经完成。

RFC 2016 先拆开了两个经常被软件界面混为一谈的问题：用户要完成什么，系统准备调用什么。订阅邮件列表、同时查询多个服务、整理返回结果，是需求；URL、协议、脚本、解释器和具体站点，是完成需求的机制。1996 年的提案希望客户端不必把两者永久焊死。

它提出的 Uniform Resource Agent，简称 URA，不是一个会自主行动的人格化角色，而是一份持久活动规范。它能够被复制、分享、修改和再次执行。不同实现可以投射到同一套“虚拟结构”，让查看者看到相似的组成，而不必先理解每一种代码载体。

六个字段把权力暴露出来

URA 的头部标识类型；activation data 列出调用者必须提供的输入；targets 用 URL 或 URN 指向资源；experience information 可以保留上次执行时间或已经发现的地址；activity script 描述条件、步骤与调度；response filter 则整理返回内容，甚至判断相关性。

这六部分提高了可读性，也让控制面不再隐形。输入模板不证明填写者有权提交数据。目标可以因为本地环境、镜像或远程执行而被替换。经验信息可能节省一次检索，也可能把过期判断带进新一轮。脚本能够继续实例化别的活动。过滤器最终决定错误页、半成品或相似字符串会不会被包装成“结果”。

RFC 的邮件列表例子说，一个实例可以封装订阅所需内容，并识别订阅结果。这里的“识别”不是邮件列表服务器出具的独立回执，而是执行链对返回内容作出的判断。用户看到的完成状态，中间隔着目标选择、协议交互、运行环境和过滤规则。

可搬运对象并不等于可搬运执行权

RFC 把实际运行环境称为 URAgency。它声明自己支持哪些 URA 类型，负责把具体实现映射到公共结构并再映射回来，知道如何激活对象，还必须满足运行时依赖。Pascal 二进制与解释型脚本可以表达相近活动，但它们要求的执行条件完全不同。对象记录协调意图，agency 才把意图变成动作。

远程 activation 让这层责任更加明显。URAgency 本身可以成为 target，一个 URA 可以调用另一个 URA，顶层活动还能编排多个下级活动。对象移动以后，解释器、库、凭据、网络位置和目标替换政策未必一起移动。相同规范在不同 agency 中启动，不等于执行了同一件事。

Silk 原型提供了一份少见的具体证据。RFC 描述了通过 Silk Desktop Internet Resource Discovery 界面运行的 Tcl URA，用户可以保存活动实例、填写激活数据并添加 Tcl 脚本。示例代码把服务地址写死，发出 HTTP 请求，再用正则表达式解析 HTML；注释还承认错误报告不足。这只能证明原型如何工作，不能推导出广泛部署。

给人看的网页不是稳定 API

RFC 2016 自己指出，服务只要轻微改变页面呈现，人眼可能几乎无感，软件解析却会直接失效。同期作者论文也把正则解析 HTML 视为核心脆弱点。面向机器的服务入口、由服务提供者维护 URA，都是缓解方法，不是对旧活动永久正确的保证。

因此，response filter 拥有解释权。它可能把错误页当数据，把局部命中当成功，或者在格式变化后安静地产出空结果。启动回执只说明执行开始；进程退出只说明某段运行结束；再次运行同一个对象，也可能访问已经更换的站点、加载不同依赖、得到不同结构。

RFC 2016 于 1996 年 10 月以 Experimental 文档发布，属于 Legacy stream。前身草案、同期论文和 Silk 记录支持“架构实验”这一判断，却不支持标准成功、采用率或现代产品谱系。它最值得保留的历史问题更窄，也更有穿透力：活动规范可以持久化，但执行权必须落在某个具体环境里。

真正需要审计的，不是对象是否保存完好，而是从需求、授权输入、解析后的目标、可重现依赖、原始响应到完成判断，是否存在一条不被“成功”二字压扁的证据链。

资料来源