我花了大半年时间在做个人 Agent 相关的事情，最大的感受是：模型负责“想”，但真正决定体验的是“跑”。我做过一个任务代办的演示：让代理去查订单、改地址、再给客服留一条备注。单看每一步都不算难，可一旦牵扯到网页表单、后端接口、人工客服三个完全不同的执行环境，方案就变得一团糟。最近社区里公开了一份草案，讲的就是怎么把这三段路串成一条通途，读完收获很大。
这份草案核心讨论一件事：个人 Agent 帮用户办事的时候，该用什么方式“跨过网页、API 和客服”。很多人的第一反应是把所有事都做成 API，但这根本不现实。大量业务仍然只存在于网页表单里，客服系统又有自己的消息协议。草案没有绕开这些复杂性，而是试图在三种界面之上搭建统一的表达和路由框架。这篇文章我会结合草案内容和我的实测经验，讲讲它到底解决了什么、还留了什么坑，以及如果你想照着做，第一版系统应该怎么搭。
1. 为什么网页、API 和客服不能靠“大模型+万能工具”硬来
个人 Agent 要替人办事，最朴素的做法是给模型接一批工具：读网页的、调接口的、发消息的。市面上很多 Demo 就是这么做的，演示视频很好看，真到上线就翻车。原因在于三个执行环境的底层规律完全不同，统一抽象很容易做浅。
1.1 网页场景的关键变量：DOM 会变、会话会断、页面会反抗
网页是最容易让代理“看起来能干成事”的环境，因为视觉上它像一个人类在操作。但网页也是最脆弱的接口。你在演示录屏里看到的按钮，很可能在你上线前就改了类名；你今天能通过的登录态，明天因为对方网站加了风控策略就失效了。
更麻烦的是网页背后有一套完整的“反自动化”压力。不是所有站点都欢迎代理来访问，有些网站会检测无头浏览器，有些会给常见自动化框架设置障碍。哪怕纯粹从技术角度讲，网页的状态也高度依赖 Cookie、会话存储和页面内异步请求。代理在网页里执行任务时，必须考虑“刷新一下页面会不会让选中元素失效”“点击之后弹窗到底有没有触发提交”这类每个人类用户都会忽略、但代理必须处理的问题。
正因如此，草案把网页当成一个独立的通道，而不是单纯当作“工具调用”的一种。通道的含义是：代理与网页之间有一套明确的执行协议，网页本身可以通过协议来告诉代理“你现在能做哪些事、哪些不能做”。这类信息没法靠猜，猜就要出问题。
1.2 API 场景的关键变量：契约稳定，但权力和边界非常清晰
API 是三者里逻辑上最理想的环境。它有明确的入参出参定义，认证体系完备，理论上代理只要拿到授权就能高效完成操作。但 API 也有自己的瓶颈——它不够“全”。
很多业务系统只把核心功能开放成 API，其他细致操作留在后台界面。举个例子，某电商平台有查询订单的接口，但“修改收货地址”这种高频需求可能就不在公开接口列表里。代理面对这种状况时，如果只绑死 API，就等于把用户限制在一半的功能区域内。
API 场景真正的难点不是调用，而是权限边界。代理要访问用户的订单、支付、发票等数据，必须有清晰的授权语义。不少现实场景里，用户同意的是“修改本次地址”，而给代理签发了一个能查看所有订单的长期令牌。这类问题在网页里不那么显眼，因为网页本身就是凭会话操作，但 API 一侧一旦滥用令牌，危害会被无限放大。
1.3 客服场景的关键变量：对面可能是人，也可能是另一个代理
客服是三者中最特殊的一项。它的特殊性在于：执行结果不完全取决于代理自己的代码，而取决于对面系统的响应。很多网站还没有把客服能力开放成结构化接口，就会要求用户通过在线聊天表单、邮件工单或电话来提交诉求。
代理接入客服的困难不是“发一条消息”，而是“发一条有效消息”。你得让对面的人类客服在几秒内理解：这个账号是谁、用户要办什么事、代理希望在多长时间内收到答复。如果代理只丢一句“请帮他改地址”，客服大概率会直接拒绝或者要求复核身份。这背后隐含着一个关键设计——代理在客服场景里必须携带足够的上下文，让接收方觉得“这条请求是可信的”。
草案的价值就在这儿：它不提供“神奇的 AI 能力”，而是提供一个让网页、API、客服三种通道都能互相理解的标准外壳。代理用同一套机制描述目标，然后由通道适配器决定具体怎么执行。
2. 草案的三层模型：意图语言、执行载体、通道适配
我读完整份草案，印象最深的是它把系统拆成了三个层次：意图语言、执行载体、通道适配。这三层听起来抽象，实际理解起来并不难。
2.1 意图层：让用户用自然语言表达，让代理人用结构化数据翻译
用户在真实场景里只会说“把这个月的电话账单对一下”或“帮我把那个订单改成下周一送货”。这类指令并不精确，代理必须先将其转成可执行的目标描述。
草案里给出的建议是：不要把自然语言原样丢给执行系统，而是转成一份结构化的任务意图对象。比如“修改默认收货地址”会被解析成：
{ "task": { "goal": "修改收货地址", "user_ref": "user_1024", "priority": "normal", "channels_allowed": ["web", "api", "customer_service"], "steps": [ { "id": "step_1", "channel": "web", "action": "goto_page", "input": { "url": "https://example.com/account/address" }, "expected_state": "address_form_loaded" }, { "id": "step_2", "channel": "web", "action": "set_field", "input": { "field": "post_code", "value": "200000" } } ], "fallback": { "after_step": "step_1", "channel": "customer_service", "message": "用户请求修改默认收货地址，已定位到地址页面，请客服协助确认身份后处理" } } }你可能注意到了，这个 JSON 完全没有让模型自由发挥的余地，每步都有明确的状态期望。它的意思是：“我期望做完 step_1 之后页面处于某个状态，如果没到预期，就按 fallback 走。” 这种方式最大的好处是，代理不会在没有任何依据的情况下反复重试一个已失效的动作。
这个设计思路很像我们平时写测试用例：不关心内部怎么做，只关心操作可验证、结果可回放。模型可以决定动作的优先级，但通道层必须保证动作是可观测的。
2.2 执行载体：把会话状态和用户授权分开
第二个让我觉得值得借鉴的点，是草案明确区分了“会话状态”和“用户授权”。这个区别在传统软件里早就有了，但放在 Agent 场景里，很多人会忘记。
会话状态指的是当前任务做到哪一步：已经打开哪个页面、填到哪个字段、服务单号是多少。用户授权则回答一个问题：“这个代理现在能替用户做哪些事”。如果两者混在一起，很容易出现一种事故：代理维护一个长期有效的 Cookie，结果它在上周的任务里拿来申请退款，这周在另一个任务里又拿同一串 Cookie 去查订单，用户根本不知道代理仍然掌握着整套密钥。
草案给出的处理建议是分离存储：会话状态可以短暂存活，任务结束就清理；用户授权必须有显式的授予与回收动作，尤其是涉及资金、支付、隐私数据的操作。这个设计在实际开发里会直接影响你的数据表结构，至少要建两张表：一张放任务进度，一张放渠道凭证授权记录。
2.3 通道适配：按照“能力清单”决定路由
通道适配是三层模型里最灵活的环节。不同网站、不同 API、不同客服系统，能力都不一样。所以草案建议每个通道都对外暴露一份能力清单，代理拿着任务目标去匹配，能走 API 就走 API，API 没有的再降级到网页，网页也搞不定的最后转客服。
我特别认同“降级”这个方向。很多 Agent 框架是反过来的：先让模型试着调网页，失败了再找接口。实际业务中，API 往往更稳定、更方便做日志审计，理应优先。真正需要网页兜底的是一些很边缘但也高频的功能，比如“修改用户头像”“填一张线下门店的问卷”，这类操作没有公开 API，只能靠网页完成。
这套路由逻辑还解决了另一个常见问题：代理不需要知道所有平台的全部细节。它只需要知道每个通道的能力列表，然后用统一的意图对象去申请执行。对系统维护者来说，新增一个渠道的成本也低很多，只需要实现一份适配器，而不需要改动代理大脑的逻辑。
3. 实操路径：如何在一个最小系统里串起三个通道
这一节我结合自己已经跑过一遍的经验，按照草案思路做一个最小验证系统。这不代表你能一步到位，但至少能梳理清楚哪些模块必须有。
3.1 Web 通道落地：先访问可控页面，再考虑全网自由操作
做 Web 通道最容易掉进的坑，是上来就让代理在任意网站上自由浏览。Agent 模型确实有很强的视觉理解能力，但让它理解一个新网站的成本远比想想中高——布局、登录状态、异构表单，每一项都要额外处理。
我建议你先挑一批“结构固定、允许自动化工具访问”的页面来做 Web 通道。比如后台管理系统、内部工具、无验证码的表单页面。在这些场景里，你可以用可访问性快照代替单纯的截图，让模型拿到结构化的字段标记，而不是靠眼睛去识别像素。
把范围限制住还有一个好处：方便设置回归测试。每一个 Web 适配器都可以针对固定页面写一套用例，页面改版时能第一时间发现。如果你一开始就让 Agent 全网乱跑，出了问题根本没法定位是页面改版，还是模型判断出错。
3.2 API 通道落地：优先接文档化接口，用网关做统一鉴权
API 通道的工程成本最低，前三周就能见效。核心模块有两个：接口描述加载和统一鉴权。建议先把你需要的接口整理成 OpenAPI 格式，让适配器能自动生成调用代码，而不是像老系统那样每个接口手写一遍。
鉴权部分要特别注意。以用户身份调第三方 API 时，优先使用短时令牌和最小权限范围。比如修改地址任务只需要写权限，就应该只发一个只有该接口域权限的令牌。别图省事去申请一个“全部权限”的大令牌，否则 Agent 在一个任务里偷拿用户其他数据，你是无法察觉的。
回调与异步处理也需要提前设计。很多 API 不会同步返回结果，你提交一个改地址请求后，它可能先返回 202，几秒钟之后通过回调通知你成功。没有异步队列的 Agent 系统，在这里就很容易卡死：代理以为操作失败，又自动重试，结果生成了两条重复工单。草案里强调的回放和去重，就是为这种情况准备的。
3.3 客服通道落地：把它设计成“最后接管出口”
客服通道的定位不应该是“普通执行渠道”，而是“最后接管出口”。当网页、API 都走不通，或者系统需要人工确认时，自动转接。
转接时要给客服足够的信息。你的 Agent 至少要生成一份简短的上下文说明，里面包含用户身份标识、任务目标、已经完成的步骤、失败原因。不要直接让客服去猜。我在测试里遇到过最抓狂的一种情况就是：系统自动给客服发一句“用户要改地址”，但没有提供任何订单号、不说明是哪个收货地址，客服只能反问三遍才弄明白要求。如果代理真是在替用户办事，它至少得有“整理好材料再递交给人类”的意识。
在实现层面，客服通道通常会对接一套消息平台。你只需要监听消息队列里的人工处理结果，然后让代理根据结果更新任务状态。异步轮询间隔不要设太短，一般 30 秒起步，否则平台会误判你是在刷接口。
3.4 回退次序：宁可停在中间态，不要反复执行危险操作
回退顺序是整套系统里最容易写错的部分。以修改地址为例，合理的顺序是 API 优先、Web 其次、客服兜底。但更重要的细节在于判定“什么时候该回退”。
如果 API 返回 402 或 403，那说明授权有问题，不是换个通道能解决的，应该直接通知用户重新授权。如果 Web 页面加载失败，可能是暂时网络抖动，可以重试一两次，仍失败就转客服。真正危险的场景是：你已经提交了“修改地址”请求但没收到确认，这时绝对不能再次执行同样的操作。你要做的是查询当前地址状态，确认结果。如果没有查询接口，那就转人工确认，而不是盲目重发。
我一开始在这个环节吃过亏。代理连续点了两次提交按钮，结果系统里生成了两条变更工单，最后用户收到的包裹被发到了两个不同的城市。教训很简单：没有去重机制的执行环境，一定会在异常情况下制造新问题。
4. 安全与可控：代理能力边界的“安全带”设计
个人 Agent 要替用户办事，信任是第一位。技术做得再炫，权限模型一塌糊涂，用户也不敢把真实账号交给你。草案在安全方面着墨不少，但落到实际项目里还需要你自己拿尺子量。
4.1 最小授权：短期令牌优先，避免整站 Cookie
在网页通道里，最不安全的设计是“让代理用用户的完整登录态去操作”。只要登录态在代理手里，代理就能看到不该看的私信、能执行不该做的操作。真要做，也应该是每次任务只产生一个受限的会话副本，并且设置非常短的过期时间。
在 API 通道里，最小授权用标准的 OAuth 权限范围表达。每个任务意图对象里都应该显式声明 scope，比如只允许读取地址列表，不允许修改订单。通道适配器在生成请求头时，必须检查当前令牌是否覆盖声明范围。这种检查不能靠模型自觉，应该是代码层的強制约束。
4.2 高风险操作强制二次确认
并不是所有任务都适合全自动。草案虽然目标是“让代理帮你办事”，但它也默认认可一个原则：风险越高，越需要把执行权重新交还给用户。
我把日常操作分成了三个等级：
| 风险等级 | 操作示例 | 处理方式 |
|---|---|---|
| 低风险 | 查询订单、修改收货地址 | 自动执行，执行后汇报 |
| 中风险 | 提交投诉、修改会员信息 | 自动执行但保留撤销入口 |
| 高风险 | 付款、删除账户、批量操作 | 需用户逐次确认 |
这个表格看起来简单，实际实施时最容易漏的是撤销入口。中风险操作即使自动执行，也必须保留“撤销”或“人工复核”的按钮。因为代理的判断不一定正确，如果不给用户留一个反悔的窗口，等于把所有失误都暴露给用户承担。
4.3 运行时观测：每一步都要可回放
个人 Agent 一旦出错，你没法像普通程序那样打开 debugger 看变量。你能依靠的就是执行日志和状态快照。所以从第一天开始，就要让系统记录每一步的完整上下文：意图对象的原始输入、模型推理出的步骤列表、每个步骤的入参出参、页面截图或接口响应记录。
这些记录不只是用来排查 bug，还可以用来给用户解释“刚才我的 Agent 到底做了什么”。一个能展示“每一步做了什么、为什么这么做”的系统，比一个只会输出最终结果的系统值得信任得多。
我在原型里做了一块只读面板，把每个任务的执行轨迹按时间线展示出来。用户能直接看到自己授权的任务被代理分解成了哪些子步骤，每步命中哪个通道，关键数据如何脱敏展示。上线后，这块面板几乎成了整个系统最受欢迎的部分——大多数用户真的担心屏幕上凭空出现的自动操作。
5. 草案几乎没有展开的硬骨头：验证码、客服交接与平台风控
草案把框架搭得比较清楚，但也明显留了一堆问题没细说。这些不是它不想写，而是现实世界里的问题比协议设计更复杂。我把我在实测里认为最难啃的三块单独拿出来聊。
5.1 验证码和滑块：现阶段只能人工介入
个人 Agent 绕过验证码，在合规上首先就不建议做。这属于平台反自动化机制的一部分，直接尝试突破验证码，既违反平台规则，也容易让整个系统陷入黑产嫌疑。
草案对此的隐含立场是：遇到验证码就把任务挂起来，等待用户手动操作完成后再继续。这看似麻烦，其实是唯一可持续的做法。我在开发时把验证码事件设计成一种特殊的“用户补充动作”，系统会暂停当前通道，向用户推送验证链接，用户通过后再恢复执行。这比让模型硬猜安全得多，也省去大量维护成本。
5.2 客服交接：要在几秒内建立起信任
当代理把任务移交给真人客服时，面对的是一个完全不同的问题。客服人员没有义务配合你的协议；他们心里想的是“我怎么确认这个请求真的是用户本人发的，而且合法有效”。
草案给出的思路是：代理在客服聊天记录里自动声明“我正代表用户 xxx 发起请求”，同时附上用户预先授权的联系方式或验证短语。实际效果取决于客服系统是否信任这个消息来源。我在测试中发现，很多客服看到消息里带“Agent”字样，第一反应是警惕，而不是配合。所以交互界面很重要：如果有条件，最好通过官方对接渠道进入，而不是模拟用户聊天。
如果你做的场景允许，建议设置一个客服专用入口，让客服能看到用户预先提交的任务凭证。凭证里包括用户 ID、任务类型、请求摘要，以及用户的确认时间。看见这些信息，客服才敢放手处理。
5.3 平台风控：自动化不等于无限次调用
只要你连续提交表单太重，任何稍微有点风控逻辑的平台都会注意到你。预案里必须考虑频率限制与退避策略。不要让代理在同一时间发起多个相同操作，也不要在收到失败后马上重试。
我在项目里给每类动作配置了独立的速率限制表。比如 Web 表单提交每 60 秒最多一次，API 调用按平台配额执行，客服消息每条间隔至少 5 分钟。这套限制原本只是出于礼貌，后来发现它确实防止了很多账号被临时限制登录的尴尬。
6. 我的建议：先从一个低风险任务跑通端到端闭环
整份草案最有价值的不是“再等等就配套齐全”，而是它给了我们一套取舍的坐标系。你看完以后不用急着展开所有能力，只需要挑一个任务，把链路打通，就能理解其中大部分设计动机。
我个人推荐的第一个任务是“修改收货地址”。原因很实际：它不涉及支付、不涉及敏感隐私，逻辑却覆盖了查询、提交、确认三个典型阶段。你完全可以照着这个步骤去搭建最小验证闭环：
- 选择任务：“把默认收货地址改成新的小区”。
- 设计流程：先尝试调用 API 查询当前地址，若存在写接口则直接提交；若无，则落到 Web 页面操作。
- 准备兜底：如果 Web 操作失败，自动生成一条客服工单，附上用户当前地址和新地址对比。
- 记录全程：把每个阶段的操作日志、状态变化、接口返回值存储下来，用于回放。
- 配置确认机制：提交完成之后，让代理自动回读一次地址，确认变更真实生效。
这个闭环跑通之后，你自然会遇到一堆草案上没有写透的细节——比如同一个地址在 API 里是字符串，在网页表单里却拆成了几个字段；比如客服工单系统不支持 Markdown；比如用户的网络环境导致第三方回调延迟高达几十秒。这些问题每一个都需要单独适配，但至少，你已经有一个稳定的框架去承载它们了。
最后再分享一个实际操作中的体会：个人 Agent 的复杂度不会因为模型变强而自动消失，反而会转移。模型越能理解用户意图，你要处理的真实世界接口就越烦琐。反过来也一样，你把网页、API、客服三个通道都理顺了，模型只需要做一件事——在合适的时机选择合适通道，并把结果清晰地转达给用户。这套协作关系，才是草案里那句“跨过网页、API 和客服”的真正含义。
