> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# 无需交出签名方，即可上线智能体执行能力

> 在智能体产品中上线跨链执行能力，而无需把签名方交给智能体。

大多数涉及链上执行的智能体产品，并不是倒在开发阶段，而是倒在评审阶段，因为把签名方交给智能体会带来一项没人愿意签字担责的风险。LI.FI 面向智能体的接口从设计上就是只读的，因此功能可以照常上线，而签名权限始终留在你已掌控的基础设施之内。

## 这对你的产品意味着什么

> **功能能够通过评审**
>
> 从工具接口到签名之间不存在任何路径，因此你的安全团队评估的风险只是一个报价请求，而不是一笔没有上限的交易。

> **不靠猜测的智能体**
>
> 状态、错误和部分完成结果都以决策流程的形式公开，这正是"只能撑过一次演示的智能体"与"可以放心长期运行的智能体"之间的差别。

> **几分钟内跑通原型**
>
> 托管服务器只需粘贴一段配置、无需安装，因此你可以在投入人力之前就验证产品想法是否可行。

> **更低的单次运行成本**
>
> [LI.FI CLI](https://docs.li.fi/cli/overview.md) 以紧凑文本而非原始 JSON 的形式返回相同能力，在循环中的每次调用都能消耗更少的 token。

![智能体调用只读的 LI.FI 工具，收到未签名的请求，并在你自己的签名方之前设有签名边界](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/agent-execution-boundary.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=92fb9adf848883be114853acb733c50f)

工具是只读的。边界就是签名发生的地方。

## 常规做法为何会停滞

赋予智能体链上能力，通常意味着给它一个签名方，而签名方是一项永久性的风险敞口。任何进入智能体上下文的内容，包括它从某个页面上读到的代币名称，此时都只差一步推理就能变成一笔交易。一笔糟糕的交易还只是小问题。更大的问题在于，你无法为"最坏能有多糟"设定上限，而这正是风险负责人在你上线之前必须回答的问题。

其背后更具体的问题是，大多数 API 是为阅读文档的开发者设计的，而不是为在多个分支之间做选择的模型设计的。智能体一旦遇到含义模糊的状态值或未记录的错误，就没有任何确定性的依据可以回退，于是只能猜测；而执行路径中的一次猜测，就是一个你会在生产环境中才发现的 bug。

## 签名在哪里发生

托管的 [MCP 服务器](https://docs.li.fi/mcp-server/overview.md)将跨链路由以工具的形式开放，供智能体发现和调用：链、代币、报价、授权额度、状态。每一个工具都是只读的。服务器不签名，也不广播。报价以未签名交易请求的形式返回，签名则在外部、在你自己的钱包基础设施中、按照你自己的规则完成。

> [!WARNING]
>
> 正是这一个设计选择，让其余部分都可以被安全地推演。即使提示注入触达了智能体，它触达的也只是一个报价请求，而不是一笔交易。

设置只需粘贴一段配置，而不是一次集成：

```json theme={"system"}
{
  "mcpServers": {
    "lifi": {
      "type": "http",
      "url": "https://mcp.li.quest/mcp"
    }
  }
}
```

它可以在任何兼容 MCP 的宿主中运行，无需安装。各宿主的具体设置请参阅[安装](https://docs.li.fi/mcp-server/installation.md)。

> [!NOTE]
>
> 在没有密钥的情况下，服务器使用公共速率限制，即每两小时 200 次请求，足以用于开发，但不足以支撑正式运行。使用密钥后，限制将提升至每分钟 200 次请求。

## 为模型阅读而编写

其余的[智能体接口](https://docs.li.fi/agents/overview.md)之所以存在，是因为智能体使用文档的方式与人不同。我们提供去除了 HTML 外壳的机器可读文档索引、供宿主自行发现该能力的发现文件，以及完整的 API 规范。

更有用的是，智能体必须正确处理的部分，都以决策流程而非叙述性文字的形式公开。

> **[五步调用流程](https://docs.li.fi/agents/quick-start/five-call-recipe.md)**
>
> 覆盖从发现到确认的最小有序调用序列。

> **[决策表](https://docs.li.fi/agents/quick-start/decision-tables.md)**
>
> 针对转账可能返回的每一种状态给出确定性分支：继续轮询、视为成功、视为已交付其他资产、视为已退款、停止并报告。

> **[错误处理手册](https://docs.li.fi/agents/reference/error-playbooks.md)**
>
> 将每一种失败映射到其原因、是否适合重试，以及应当如何告知用户。

LI.FI 的能力还以预构建智能体技能的形式发布在主要的智能体技能目录中，因此跨链执行可以作为原生能力直接添加，而无需你自行编写。

## 上线前需要决定的事项

> **你的签名方将代表哪些地址执行操作**
>
> 在签名方层面强制执行，而不是在提示词中约定。提示词可能被说服放弃规则，签名策略则不会。

> **每个智能体、每个会话的支出限额**
>
> 一个可以请求任意规模报价的智能体，终究会请求一笔这样的报价，而唯一能让它变得无害的地方，是智能体触及不到的那一层。

> **部分完成的结果对智能体的计划意味着什么**
>
> 一笔转账以交付了不同但相关的资产而完成，在协议层面算作成功，在计划层面却可能是失败，智能体需要将这种区别明确编码，而不是自行推断。请参阅[部分完成](https://docs.li.fi/agents/workflows/partial-completion.md)。

> **智能体可以自行重试，还是必须先询问**
>
> 两种做法都可行。不可行的是，智能体重试了一笔资金操作，却没有记录下这一行为。

## 从哪里开始

将一个兼容 MCP 的宿主指向托管服务器，并让它为一次跨链转移报价。这只需一分钟，而它能让你对集成形态的了解，胜过任何阅读。然后再构建签名侧，也就是始终归你掌控的部分：地址策略、限额和审批。

> **[MCP 服务器概览](https://docs.li.fi/mcp-server/overview.md)**
>
> 托管设置、可用工具和速率限制。

> **[智能体集成](https://docs.li.fi/agents/overview.md)**
>
> 调用序列、决策表和错误处理手册。

> **[可用工具](https://docs.li.fi/mcp-server/tools.md)**
>
> 所有 MCP 工具的完整参考。

> **[执行工作流](https://docs.li.fi/agents/workflows/execution.md)**
>
> 智能体循环中的授权、执行和状态恢复。

> **[联系 LI.FI 团队](https://docs.li.fi/introduction/integrating-lifi/partnership-opportunities.md)**
>
> 告诉我们你的智能体的调用量以及你希望它运行的流程。我们会为你配置合适的 API 密钥和限额。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.