网页的“读者”正在悄然改变

过去三十年，HTML 一直解决一个核心问题：怎么把内容展示给人看。表格、段落、图片、表单，这些都是围绕“人眼阅读”设计的，简单又有效。

但现在情况变了。网页的主要“读者”不再只是人类，而是各种自主 AI 代理。它们会读取数据、做决策、执行操作。问题是：HTML 对它们来说其实很不友好。

AI 代理遇到普通网页时，得硬着头皮去：

• 从视觉布局里猜结构
• 通过概率推断哪些信息重要
• 反向推敲表单流程
• 自行判断隐私和授权边界

每一次猜测都增加出错风险。

鸭子模型：表里如一的文档

ANML（Agentic Notation Markup Language）用了一个很形象的比喻：鸭子在水面上看起来优雅简单，水面下却是一套复杂而协调的系统。

ANML 文档（简称 duckument）正是这样。对人来说，它读起来清晰自然；对 AI 代理来说，它提供了所有必要的信息：

• 明确的服务能力，而非需要推断的流程
• 机器可读的限制条件，而不是靠运气遵守的规则
• 结构化的知识交换，而不是一堆乱七八糟的数据
• 清晰的隐私边界，而不是一长串代理根本不看的政策

关键在于，它没有牺牲可读性，而是做了增强。

让 AI 代理少猜、多做

传统 API 让 AI 代理很为难。它们必须尽量减少猜测，因为每一次猜测都消耗算力、增加延迟、可能出错。

ANML 让意图变得明确。比如一个演唱会售票服务，不需要代理去“猜”有没有早鸟票，而是直接声明：时间范围、条件、限制，一目了然。

同时，ANML 也保证了确定性。代理执行的是你明确定义的流程，而不是“大概这样”的猜测。隐私方面更是如此——它把隐私规则直接写进标记里，让代理必须尊重这些规则，而不是后

两种格式，适配不同场景

ANML 同时支持 XML 和 JSON。

XML 适合直接阅读和编写。结构清晰，自带说明，方便开发者理解。

JSON 适合程序生成和代理消费。你的后端可以直接生成，代理也能直接读取，没有额外转换层。

两种格式都权威，不存在“哪个才是正版”的问题。

鸭子文档里有什么

一个 ANML 文档包含五个核心部分：

• 信息：结构化的语义数据，不需要推断。比如价格、可用性、条件，直接声明。
• 交互：明确绑定到 HTTP 方法和 endpoints 的操作。代理知道如何执行动作，不用再猜。
• 知识：双向信息交换。服务告诉代理自己知道什么，也明确告诉代理需要从用户那里获取什么。
• 限制：代理必须遵守的规则。包括隐私限制、授权要求，这些是机器可评估的条件。
• 状态：标记当前处于多步流程的哪一步。代理知道上一步做了什么，下一步该

为什么值得关注

如果你正在构建服务，而且这些服务未来会面对 AI 代理——这个概率越来越高——那么 ANML 就是一种升级。

目前大多数服务都不是为代理设计的。它们是为人类开发者定制的。当 AI 代理访问这些服务时，靠的是“摸黑”猜测。这就像戴着手套操作手机，勉强能用，但效率低、风险高。

ANML 的核心思想是：设计服务时，让代理能“理解”而不是“猜测”。

对开发者来说，好处包括：

• 外部代理和你的服务 interact 时，更可靠
• API 规范更清晰，人类和机器都能信任
• 隐私规则可以真正执行
• AI 系统处理数据时，减少不必要的猜测消耗

更大格局

我们正在看到“代理互联网”的出现——它像现在 HTML 网页一样，专为自主代理优化。

HTML 并没有因为 JavaScript 框架出现而消失。HTTP 也没有因为 REST API 流行而被取代。ANML 不是替代 HTML，而是新增一层抽象——专

准备好了吗

如果你正在思考 agent-first 架构、API 设计，或者想让你的服务更好地适应自主代理，现在正是探索 ANML 规范的时候。

从“为人类优化”到“为代理优化”，这个转变正在开始。如果你是在 fintech、e-commerce、SaaS 等领域，这种 change 尤为重要。

未来的 API 不仅仅是 endpoints 和 documentation，而是明确的、机器可执行的指令——既 respecting 用户自主权，也 respecting 服务边界。

Duckuments 正在到来。你的服务准备好了吗？