我花了大半年时间在做个人 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 就走 APIAPI 没有的再降级到网页网页也搞不定的最后转客服。我特别认同“降级”这个方向。很多 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 和客服”的真正含义。