> For the complete documentation index, see [llms.txt](https://nexon-3.gitbook.io/nexon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nexon-3.gitbook.io/nexon-docs/zh/di-er-bu-fen-jia-zhi-lian-jie-ming-ti/02-the-translator/intent-over-operation.md).

# 表达意图，而非操作产品

意图是一次有边界的结果请求，不是给 Agent 的空白支票；路径要能被看见、被撤销、被追责。

传统金融软件是围绕**操作**组织的：选市场、选资产、填金额、设订单类型、把钱转出去、换汇，然后打开下一个 App 从头再来一遍。界面把所有按钮都给了你，也把整个计划留给了你。

意图比操作高一层。它描述的是你想要的结果，以及追这个结果的过程中必须一直成立的边界。

> 「留出这笔储备不动，只用这几个账户里的余额，把总成本告诉我，动任何一分钱之前先问我。」

这是一句意图。它不是「系统可以随便动它看得见的任何账户」。

自然语言让人更容易一口气说完这些条件，但真正能被执行的对象必须是结构化、可校验的。一条意图在生成路径之前，至少要能表示：

* 目标结果与金额；
* 允许使用的资产与账户；
* **绝不能动**的资产、场所或类别；
* 截止时间与路径有效期；
* 可接受的价格波动、费用与执行上限；
* 身份、地域与产品资格约束；
* 每一段是逐段审批，还是走一条窄口径的长期规则；
* 价格、库存或资格变化时的兜底动作。

**模糊不是权限。** 关键字段缺了，正确的动作是追问、收窄，或者停下来。

## 一次完整的往返 <a href="#one-complete-round-trip" id="one-complete-round-trip"></a>

假设一个场景：用一笔划定好的数字资产预算完成一次旅行预订，同时另一笔储备一分不动。对话界面可以很简单，底下的控制不能省。

{% tabs %}
{% tab title="1 · 意图" %}
系统记下目的地、日期、预算上限、不许动的资产、储备下限和审批偏好，并且把**软偏好**（「离会场近一点」）和**硬约束**（「储备不得低于这个数」）分开存。

它同时标记出请求里哪些部分含敏感信息，以及这些信息能被保留多久。旅行、财务和关系信息是高度敏感的，路径需要的是已批准的那几条约束，不是产生它们的整段对话。
{% endtab %}

{% tab title="2 · 路径" %}
运行时提出候选步骤：一次资产兑换、一种受支持的支付方式、一次供应商预订。每一项是独立分段，彼此之间有依赖。

兑换报价过期了，购买段就不能拿旧假设继续跑。没有直接支持的路径时，系统应该直说没有——而不是编一个看起来能成的方案出来。
{% endtab %}

{% tab title="3 · 策略校验" %}
路径要连过四层规则，模型的置信度替代不了其中任何一层：

* **用户策略** —— 个人限额、白名单、储备下限；
* **产品策略** —— 余额、最低订单量、已披露条款；
* **场所策略** —— 账户状态与辖区资格；
* **供应商策略** —— 库存与履约条件。

涉及 Staking Platform 时，校验按真实机制走：28% 按当时 1 U 等值买入 EXON 存入燃料钱包，其余兑换 XO 进入质押。界面不能把燃料买入说成手续费，也不能把燃料钱包说成可转出的余额。
{% endtab %}

{% tab title="4 · 用户审批" %}
审批是一个能读懂的决策对象：动什么资产、最大金额是多少、去哪里、谁执行、什么时候过期、预计拿到什么凭证。

一个不展示这些事实、只让人点「确认」的签名，形式上是同意，实质上没有控制。

权限应该收到**完成目标所需的最小范围**。用户可以批准一笔交易、一组有依赖关系的分段，或者一条限额和时限都写死的长期规则。换目的地、提金额、扩大资产范围、延长期限——都要重新审批。
{% endtab %}

{% tab title="5 · 执行" %}
每一段只由负责它的系统执行。Agent 可以准备交易、比价、调用获准接口，但不会因此变成交易所、托管人、发卡机构或商户。

状态至少要能区分：已提议、已批准、已提交、已结算、已履约、失败、已退款。**「处理中」不能是一个永久状态。**
{% endtab %}

{% tab title="6 · 凭证" %}
最终记录把当初那条路径和实际发生的事对起来：标识、时间、价格与费用、用掉的权限、跟报价偏离了多少、责任方是谁、后面归谁跟进。

现实消费必须把**支付结算**和**商品/服务履约**记成两个事件。
{% endtab %}
{% endtabs %}

## 失败本来就是路径的一部分 <a href="#failure-is-part-of-the-route" id="failure-is-part-of-the-route"></a>

一个正经的意图系统会在需要之前就把失败路径讲清楚。

| 失败情形             | 安全默认动作                |
| ---------------- | --------------------- |
| 审批前报价过期          | 重新报价，重新审批             |
| 资格校验没过           | 停掉这一段，说明是哪条规则挡住的      |
| 余额变了             | 重新计算，**绝不**悄悄换一种资产顶上  |
| 前段已结算、后段失败       | 保住凭证，进入已披露的退款、对冲或争议流程 |
| 供应商没履约           | 即使付款成功，履约也标为失败，转责任流程  |
| Agent 的输出与产品规则冲突 | 产品规则优先，拒绝执行           |

不是所有动作都能回滚。已结算的交易可能只能按新价做一笔反向交易；链上转账可能不可逆；商户退款需要时间。所以界面必须用准确的词——取消、撤销权限、退款、反向交易、对冲、重试——而不是一个万能的「撤回」。

## 谁负责什么 <a href="#who-owns-what" id="who-owns-what"></a>

| 角色                   | 负责                          |
| -------------------- | --------------------------- |
| **用户**               | 定义目标、批准有限权限、承担已披露的市场与本金风险   |
| **编排层**              | 解析意图、构造候选路径、执行用户策略、记录决策     |
| **执行场所**             | 订单、结算、托管与资格控制               |
| **Staking Platform** | 按已发布版本应用经济机制                |
| **商户 / 服务供应商**       | 库存、交付、取消与争议                 |
| **数据与模型**            | 提供信号。它们的输出是待评估的信息，不是必须服从的权威 |

这张表就是 NEXON 叫「连接网络」而不是「全能 App」的原因：体验可以统一，责任分工不能模糊。

## 持币不等于授权 <a href="#holding-a-token-is-not-an-authorization" id="holding-a-token-is-not-an-authorization"></a>

XO 是价值锚，当前承载质押本金；EXON 是流通引擎，当前是现货、释放、买入、校验与销毁资产。持有其中任何一种，都不会自动让 Agent 获得花你账户余额、跳过策略校验或执行受监管交易的权限。**权限来自用户和责任执行系统，不来自余额。**

意图之所以是个更好的抽象，恰恰因为它最后落在可见的操作上。它隐藏的是重复导航，不是后果；它省掉的是人工翻译，不是用户的决定权。

*上一节：*[*价值翻译器*](/nexon-docs/zh/di-er-bu-fen-jia-zhi-lian-jie-ming-ti/02-the-translator.md) *· 下一节：*[*这不是「AI + 支付」*](/nexon-docs/zh/di-er-bu-fen-jia-zhi-lian-jie-ming-ti/02-the-translator/not-ai-plus-payments.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://nexon-3.gitbook.io/nexon-docs/zh/di-er-bu-fen-jia-zhi-lian-jie-ming-ti/02-the-translator/intent-over-operation.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.