企业官网建设流程全解析

1. 从“能对话”到“能办事”：AI Agent 的现状与缺口

1.1 为什么邮箱和钱包是 Agent 的分水岭

过去一年我一直在折腾各种 AI Agent 的落地场景，从最早的纯 Prompt 编排，到后来接上工具调用，再到最近开始给 Agent 配邮箱和钱包。说实话，给 Agent 一个邮箱和钱包，和让它真正做成一门生意，中间隔着的距离比大多数人想象的要远得多。

先说清楚这两个东西为什么重要。邮箱本质上是 Agent 的身份锚点——它能注册账号、接收验证码、收发正式通知、留存沟通记录。钱包本质上是 Agent 的结算能力——它能收付款、能持有资产、能执行链上或链下的价值转移。这两样东西一配上，Agent 就从“一个会聊天的程序”变成了“一个能独立参与经济活动的实体”。

但这里有个很关键的认知：能收邮件不等于能处理业务，能转账不等于能完成交易。我见过太多演示视频里 Agent 自动发了一封邮件、自动转了一笔账，观众觉得很酷，但真放到生产环境里，五个环节全部掉链子。

1.2 五个缺失环节的全景概览

我把这五个环节拆成下面这张表，后面会逐个展开讲：

这五个环节不是并列关系，而是层层递进的。身份没解决，通信就是空谈；通信没打通，编排就是自嗨；编排跑不通，结算就是送钱；结算没风控，合规就是纸上谈兵。

1.3 谁适合看这篇内容

如果你正在做 AI Agent 的开发，尤其是想让 Agent 从“玩具”变成“工具”甚至“员工”，这篇内容就是写给你的。我不讲虚的架构图，只讲我在实际搭建过程中踩过的坑、试过的方案、以及目前能跑通的路径。需要一点基础的 Agent 开发经验，但不需要你是分布式系统专家。

2. 身份与信任：Agent 的“身份证”怎么建

2.1 邮箱不是随便注册一个就完事

很多人给 Agent 配邮箱的第一反应是去注册一个免费邮箱。我一开始也是这么干的，结果发现几个致命问题。

第一，风控拦截。主流邮箱服务商对自动化注册和登录有非常严格的风控。你如果用脚本去注册，大概率会触发验证码、手机验证甚至直接封号。我试过用临时邮箱服务，但临时邮箱的问题是无法长期持有，而且很多平台不认临时邮箱域名。

第二，邮箱后缀影响信任度。这一点很微妙但很真实。当你用一个@gmail.com或者@outlook.com的邮箱去和商业伙伴沟通时，对方默认你是一个真人。但如果你用的是某个不知名域名的邮箱，对方的垃圾邮件过滤器可能直接把你拦掉。我实测下来，自定义域名的邮箱在 B2B 场景下的送达率明显低于主流邮箱，除非你的域名已经有足够的信誉积累。

第三，多 Agent 场景下的邮箱管理。如果你有多个 Agent 需要独立身份，你不能让它们共用一个邮箱。这时候你需要一套邮箱分配和轮换机制。我的做法是：核心 Agent 用固定域名邮箱，临时任务 Agent 用可回收的临时邮箱，但临时邮箱只用于低信任场景。

注意：不要用同一个 IP 批量注册邮箱，也不要用同一个浏览器指纹。这两条是风控系统最基础的检测维度。

2.2 钱包地址作为 Agent 的链上身份

钱包地址在 Agent 场景下有两个作用：收款和身份标识。

收款很好理解，但身份标识这一点很多人忽略了。在链上世界，一个钱包地址的历史交易记录就是它的信用档案。如果一个 Agent 的钱包地址有长期的、稳定的交易记录，那它在和其他 Agent 或人类交互时，就天然带有一定的信任背书。

我目前的做法是：给每个 Agent 分配一个独立的钱包地址，并且这个地址只用于该 Agent 的业务活动。不要混用，不要图省事。混用会导致两个问题：一是无法独立核算每个 Agent 的收支，二是如果某个 Agent 出了问题，会牵连到其他 Agent 的资产安全。

钱包类型的选择上，热钱包适合高频小额结算，冷钱包适合大额资产存储。但 Agent 场景下，热钱包是刚需，因为 Agent 需要自动签名交易。冷钱包的物理隔离特性决定了它无法被 Agent 直接调用。所以我的方案是：热钱包放少量运营资金，冷钱包作为资金归集和储备。

2.3 身份验证的实操路径

给 Agent 建立可信身份，我目前跑通的路径是这样的：

1. 注册主流邮箱：手动注册，不要用脚本。注册完成后开启 IMAP/SMTP，拿到授权码。
2. 配置自定义域名邮箱：如果业务需要，用域名邮箱作为对外正式沟通渠道。
3. 生成钱包：用代码生成助记词和私钥，私钥加密存储，助记词离线备份。
4. 建立身份映射表：把 Agent ID、邮箱、钱包地址、API Key 等信息统一管理。

这个映射表是整个系统的核心，我建议用数据库来管理，不要用配置文件。因为后续你会需要频繁查询和更新。

3. 通信协议：Agent 之间怎么“说人话”

3.1 邮件通信的局限性

邮箱能通信，但邮件的通信效率极低。一封邮件从发出到对方 Agent 解析，中间涉及 SMTP 传输、IMAP 拉取、正文解析、意图识别等多个环节。任何一个环节出问题，通信就断了。

我实测下来，邮件通信最大的问题是非结构化。人类写邮件可以很随意，但 Agent 解析邮件需要结构化数据。你让一个 Agent 去读另一封自然语言邮件，然后提取出“谁、要什么、什么时候、多少钱”，这个准确率在复杂场景下很难超过 80%。

所以我的结论是：邮件适合作为通知渠道和正式记录渠道，不适合作为 Agent 之间的主要通信协议。

3.2 MCP 与 A2A：两种协议的分工

MCP 和 A2A 是目前 Agent 通信领域两个绕不开的概念。我用大白话解释一下它们的区别。

MCP 解决的是“Agent 怎么调用工具”的问题。比如你的 Agent 需要查数据库、需要调 API、需要读写文件，MCP 提供了一套标准化的接口描述和调用方式。你可以把它理解成 Agent 的“USB 接口”——不管什么工具，只要符合 MCP 规范，Agent 就能插上就用。

A2A 解决的是“Agent 怎么和其他 Agent 对话”的问题。它定义了一套 Agent 之间的通信协议，包括能力发现、任务协商、状态同步等。你可以把它理解成 Agent 的“社交礼仪”——怎么打招呼、怎么提需求、怎么确认收到、怎么反馈结果。

这两个协议不是竞争关系，而是互补关系。一个 Agent 对内用 MCP 调工具，对外用 A2A 和其他 Agent 协作。

3.3 通信协议选型的实操建议

如果你现在要搭建 Agent 通信体系，我的建议是：

• 内部工具调用：优先用 MCP。目前主流框架对 MCP 的支持已经比较成熟，接入成本低。
• Agent 间协作：A2A 是方向，但生态还在早期。如果现在就要落地，可以先用 HTTP + JSON 自定义协议，但接口设计要参考 A2A 的思路。
• 对外通知：邮件 + Webhook 组合。邮件用于正式记录，Webhook 用于实时触发。

实操心得：不要试图用一个协议解决所有通信问题。我见过有人想用邮件协议承载所有 Agent 通信，结果系统复杂度爆炸，维护成本极高。

4. 任务编排：从“一句话需求”到“可执行步骤”

4.1 任务拆解的核心逻辑

Agent 做生意的本质是接活、干活、交活。但人类给的需求往往是一句话：“帮我写一篇关于 AI Agent 的文章，预算 500，三天内交付。”

这句话里包含了多个隐含信息：文章主题、字数要求、交付时间、预算范围、质量标准。Agent 需要把这些隐含信息提取出来，拆解成可执行的步骤。

我的做法是三层拆解：

• 第一层：意图识别。判断这是一个什么类型的任务——内容创作、数据处理、代码开发、还是信息查询。
• 第二层：约束提取。把预算、时间、质量要求等约束条件结构化。
• 第三层：步骤生成。根据任务类型和约束条件，生成具体的执行步骤。

这三层拆解听起来简单，但实际做的时候，第二层是最容易出问题的。因为人类的约束条件往往是模糊的，“质量好一点”这种要求，Agent 很难量化。

4.2 多步任务的状态管理

一个任务拆成十步，执行到第七步的时候失败了，怎么办？

我踩过的坑是：没有做状态持久化。Agent 执行到一半，进程重启，所有上下文丢失，任务从头开始。这在演示场景下无所谓，但在生产环境下是灾难性的。

后来我改成每一步都写状态到数据库，包括当前步骤、已完成步骤、中间结果、错误信息。这样即使进程重启，也能从断点恢复。

状态管理的另一个关键是超时处理。Agent 执行某一步骤时，如果对方 Agent 迟迟不响应，不能无限等待。我设置的是：单步超时 5 分钟，整体任务超时 2 小时。超时后触发告警，并记录超时原因。

4.3 编排引擎的选型对比

我目前用的是自研状态机 + 消息队列的组合。状态机负责逻辑编排，消息队列负责步骤间的异步通信。这个组合的灵活性最高，但开发成本也确实不低。

5. 结算与风控：钱怎么收、怎么付、怎么防跑单

5.1 结算方式的选择

Agent 之间的结算，目前我能跑通的方案有三种：

第一种：链上结算。用稳定币在链上转账，优点是透明、可追溯、无需信任中介。缺点是 gas 费波动、确认时间不确定、链上拥堵时体验差。

第二种：平台内结算。如果 Agent 都在同一个平台内，可以用平台积分或内部账本结算。优点是快、零手续费。缺点是平台风险——平台倒了，积分就是废纸。

第三种：预授权 + 后结算。先冻结一笔资金，任务完成后解冻并转账。优点是兼顾信任和效率。缺点是需要一个可信的第三方来执行冻结和解冻。

我目前的方案是链上结算为主，平台内结算为辅。小额高频用平台内结算，大额低频用链上结算。

5.2 风控的核心规则

Agent 做生意的风控，核心就三条：

1. 单笔限额：任何一笔交易不能超过预设上限。我设的是单笔不超过 100 USDT，日累计不超过 500 USDT。
2. 对手方白名单：只和已知的、可信的 Agent 或地址交易。新对手方需要人工审核。
3. 交付验证：付款前必须验证交付物。验证方式可以是人工确认，也可以是自动化的质量检查。

这三条规则听起来简单，但执行起来需要一套完整的系统支撑。尤其是第三条，自动化质量检查的准确率直接决定了风控的有效性。

5.3 跑单与纠纷处理

跑单是 Agent 生意中最现实的风险。我遇到过的情况包括：对方 Agent 收了钱不交付、交付物质量不达标、交付延迟导致业务损失。

处理这些纠纷，我的经验是：事前预防比事后追责重要得多。具体做法包括：

• 大额交易必须分阶段付款，比如 30% 预付款、40% 中期款、30% 尾款。
• 交付物必须经过自动化检查 + 人工抽检双重验证。
• 建立黑名单机制，跑单的 Agent 地址永久拉黑。

注意：链上交易是不可逆的。一旦转账确认，资金无法追回。所以链上结算的风控要求比传统支付高得多。

6. 合规与审计：出了事谁负责

6.1 审计日志的设计

Agent 的每一个决策、每一次通信、每一笔交易，都必须有日志记录。这不是为了好看，而是为了出问题时能追溯。

我的日志设计包含以下字段：

• 时间戳
• Agent ID
• 操作类型（通信/决策/交易）
• 输入数据
• 输出数据
• 决策依据
• 执行结果

这些日志需要不可篡改。我的做法是定期把日志的哈希值写到链上，这样即使本地日志被篡改，链上的哈希也能证明原始日志的存在。

6.2 责任边界的划分

Agent 出了事，责任算谁的？这个问题目前没有标准答案，但我的做法是在协议里写清楚。

具体来说，我会在 Agent 之间的协作协议里明确：

• 任务描述由谁提供，准确性由谁负责
• 执行过程中的错误由谁承担
• 交付物的质量标准由谁定义
• 纠纷的解决机制是什么

这些条款不是法律文件，但它们是技术层面的责任约定。有了这些约定，出问题时至少有一个协商的基础。

6.3 合规的底线思维

我不打算在这里讨论具体的法律法规，因为不同地区的规则差异很大。但有一条底线是通用的：不要让你的 Agent 做任何人类不能合法做的事情。

具体来说：

• 不要用 Agent 进行欺诈、洗钱、逃税等违法活动
• 不要用 Agent 绕过平台的风控机制
• 不要用 Agent 侵犯他人的知识产权或隐私

这些底线不是技术问题，而是设计者的选择。你在设计 Agent 系统时，就应该把这些约束写进代码里，而不是等出了问题再补救。

7. 实操复盘：我踩过的五个坑

7.1 邮箱被封导致业务中断

早期我用脚本批量注册邮箱，结果被风控系统识别，一夜之间封了十几个邮箱。业务直接中断，因为所有 Agent 的身份都绑在这些邮箱上。

教训：邮箱注册必须手动，或者用可靠的邮箱服务商提供的 API。不要贪图省事用脚本批量注册。

7.2 钱包私钥泄露

有一次我把私钥写在了配置文件里，然后不小心把配置文件提交到了公开仓库。虽然发现得早，没有造成实际损失，但这件事让我后背发凉。

教训：私钥必须加密存储，配置文件必须加入.gitignore，提交前必须检查。

7.3 任务状态丢失

前面提到过，Agent 执行到一半进程重启，所有上下文丢失。这个问题我遇到过三次，每次都要手动恢复任务。

教训：状态持久化不是可选项，是必选项。每一步都要写数据库。

7.4 通信协议不兼容

我早期用自定义的 JSON 格式做 Agent 通信，后来想接入一个第三方 Agent，发现双方的协议完全不兼容。改协议的成本极高，最后只能放弃合作。

教训：通信协议尽量向主流标准靠拢，哪怕标准还不成熟，也比自定义强。

7.5 结算金额算错

有一次 Agent 自动结算时，把 USDT 的小数点算错了，多付了 100 倍。幸好对方 Agent 是可信的，把钱退了回来。

教训：金额计算必须有单元测试，必须有上限校验，必须有人工复核环节。

8. 常见问题速查

9. 后续可以扩展的方向

这套体系目前能跑通，但离“成熟”还有距离。我接下来打算在几个方向上继续折腾：

第一，A2A 协议的深度集成。目前 A2A 的生态还在早期，但方向是对的。等标准稳定后，我会把 Agent 间的通信全部迁移到 A2A 上。

第二，自动化质量检查。目前交付物的质量检查还有很大一部分依赖人工。我在尝试用另一个 Agent 来做质量检查，但准确率还不够高。

第三，多链结算。目前只支持一条链上的结算，后续想扩展到多链，让 Agent 可以根据 gas 费和确认时间自动选择最优链。

第四，声誉系统。给每个 Agent 建立链上声誉，记录它的历史交易、交付质量、纠纷记录。这样新 Agent 接入时，可以通过声誉快速判断是否可信。

这些方向都不容易，但每一个都值得做。Agent 做生意的门槛正在降低，但真正做成一门生意，需要的远不止一个邮箱和一个钱包。