最近一份代号Poppy的草案在个人Agent开发者和自动化落地圈子里讨论度很高。它聊的事情非常具体个人Agent替用户办事的时候怎样把网页界面操作、API调用、人工客服转接这三条完全不同的通道统一起来。这个议题表面看是协议层面的定义问题实际上决定了Agent能不能从“会回答问题”走向“真把事办完”。我读完这份公开草案之后最直观的感受是它没有停留在“工具调用协议”的层面而是试图把整个“办事过程”变成可表述、可交接、可恢复的状态流。这篇文章我会从草案要解决的问题、核心机制、落地示例和争议点几个维度展开尽量讲人话适合正在做Agent工程化、RPA流程改造和企业级人机协同的开发者参考。1. 草案在解决什么问题从会聊天到能办事的最后一公里个人Agent现在面临的最大困境不是什么模型能力不够而是它没办法稳定地“把一件事从头办到尾”。原因很简单现实世界里的任务从来不只在一个系统里完成。你要订一张机票可能要先在企业审批系统里填单再去航司网站查航班最后还要在差旅平台上提交发票。每个环节暴露出来的交互方式都不一样有网页、有接口、还有人。1.1 为什么网页、API、客服三件事必须放在一起谈很多做Agent的人习惯把通道分开处理网页交给RPAAPI交给编排客服交给工单系统。这恰恰是问题所在。先说网页。大量存量业务系统根本没有公开API网页是唯一可操作的入口。好处是覆盖面极广坏处是DOM结构一调整Agent就抓瞎。更麻烦的是网页交互本身充满歧义一个“提交”按钮到底是提交整张表单还是提交当前区块一个下拉框要不要等异步数据加载完成这些问题的答案不在HTML里而在人的使用习惯里。Agent要稳定操作网页需要的不是更多爬虫技巧而是一套描述“页面能做什么”的语义层。再说API。API比网页友好得多有结构、有权限、有文档。但API的核心难题是“发现”和“组合”。Agent怎么知道当前场景下该调哪个接口如果A接口返回的数据和B接口需要的参数格式不一致谁来负责转换这不是网络层的问题是上下文的衔接问题。很多失败的Agent调用并不是网络断了而是因为任务状态没有在不同服务之间传递清楚。最后说客服。最容易被低估的是这条通道。Agent跑得再顺总有权限不足、数据异常、模型不确定的时候这时必须把问题交给人来处理。难的不是生成一张工单而是让接手的人能秒懂“之前发生了什么、已经试过什么、现在卡在哪、需要我做什么”。没有这个结构化的交接机制人工介入反而变成一场灾难。你会看到Agent执行到一半抛出一段报错日志人类接手后要花十分钟重新拼上下文。把这三条通道放在一个草案里谈核心原因就是真实任务天然是跨通道的只有一起定义才能让Agent在网页、API、人之间来回切换时保持状态连续。1.2 与既有草案的定位差异不是工具协议是任务描述协议Poppy草案出来之前行业内已经有几类相关方案。比如面向工具输入的上下文协议大家习惯叫TAP还有面向Agent之间上下文共享的LMC。这些方案解决的是“Agent调用工具时上下文怎么传”的问题重点在函数参数、返回值和上下文压缩。Poppy的定位不太一样。它关心的不是“单个工具调得好不好”而是“整件事办得顺不顺”。草案里大量篇幅在讲任务编排、状态演化、人工衔接这些内容有点像一个工作流引擎的参数规范但同时又强调执行时的可理解性。你可以把TAP理解成“给Agent一双好用的手”把LMC理解成“让多个Agent能对话”而Poppy更像是在定义“Agent手里那张办事流程图应该写成什么样”。这个区别很关键。前者决定了工具能力能否被调用后者决定了多个步骤组合在一起时是否被人和机器一致理解。草案里也明确表达了它不打算取代TAP和LMC而是希望在更上一层提供一套统一的描述框架让不同实现之间可以互相读懂对方的进度和意图。1.3 草案的独特立场把“表示层”拉回Agent上下文Poppy草案里我印象最深的一个主张是Agent不能只看DOM源码应该拿到一层“界面语义”。这个主张把网页从“抓取对象”变成了“目标操作空间”。举个例子。一个RPA流程要登录供应商网站传统做法是定位输入框的CSS选择器、找到登录按钮、模拟点击。这套逻辑和底层HTML高度耦合只要前端工程师改个class名流程就断。草案的思路完全不同它提出用一种稳定的语义描述来标记页面能力比如“这是一个表单提交后会产生事件”“这是一个列表支持筛选和排序”。Agent只需要读懂语义描述就能操作任意长得不一样但功能相似的页面。这件事单独拎出来不难理解难的是它把“表示层”正式变成了Agent上下文的一部分。过去网页自动化一直游离在Agent认知之外现在草案等于承认了一件事网页也是Agent需要理解的世界状态而且应该用和API一致的方式进入上下文。2. 核心机制拆解DAG之外迁移结构描述才是主角草案的技术框架分几块。任务编排模型、迁移结构描述、状态演化与存档是其中最核心的机制。单独看每个部分都不算颠覆但组合在一起确实解决了一个长期没人定义清楚的问题Agent做到一半人和另一个系统怎么接手。2.1 任务编排模型超图表达依赖关系早期Agent执行任务基本是线性链思考一步、调用一个工具、看到结果、再思考下一步。后来大家发现复杂任务需要并行和分支DAG有向无环图就成了主流描述方式。Poppy草案在此基础上又往前走了一步它建议用超图来表达任务依赖。超图和普通图的最大区别是一条边可以连接任意数量的节点。这意味着一个步骤可以同时依赖多个前置步骤的结果一个产物流转出去之后也能同时被多个下游步骤消费。这个建模能力对真实任务很有用。一个“报销”流程可能需要同时读取审批结果和发票文件缺一个都没法提交一个“发布”流程可能需要在更新数据库之后同时触发通知和写审计日志。用超图表达这些关系比堆DAG要自然得多。不过我自己的看法是超图本身不是银弹。草案把超图作为任务编排的描述标准更多是希望实现方提供一个足够通用的数据模型。你完全可以用现有的DAG引擎做底层运行只要对外暴露的协议能表达超图关系就行。协议的真正价值在语义层不在图论。2.2 迁移结构描述Agent和人的交接单草案里有一个让我眼前一亮的定义迁移结构描述Task Migration Description。这个概念在我们做RPA和客服系统的人看来就是一张结构化的“转接单”。什么是转接单客服系统里最典型的一个场景是一线客服处理不了深度技术问题要转给二线专家。好的转接单会包含用户原始描述、已经做过的排查步骤、当前订单状态、客户情绪倾向、需要二线确认的问题清单。如果这些信息缺失二线客服接起来会非常痛苦一切都要重问。Agent和人工之间的交接本质上一模一样。草案把迁移结构描述定义为一组标准字段包括当前任务状态快照、已执行动作回溯、待决策问题、可用上下文引用、对人类回复的格式要求。收到迁移描述的人或系统不需要重新读原始日志就能准确知道Agent在想什么、卡在哪、需要什么决策。这件事看起来不复杂但绝大多数Agent系统到现在都没做。任务出错就是一句“调用失败”根本没有交接语义。从工程角度看迁移结构描述是一次非常聪明的抽象。它把“要不要转人工”决策和“转人工时带什么”的机制分开。Agent自己可以判断什么时候该移交但无论何时移交目标方拿到的都应该是同一个结构的数据包。2.3 状态演化与会话存档可审计的执行历史草案的另一块内容是状态演化模型。整个办事过程被建模成一组状态节点比如等待输入、处理中、等待人工、完成、失败、中止。任何一次状态跳转都会产生一个事件事件包含触发原因、操作者Agent或人类、关联的迁移描述、时间戳。这套机制对排故障极其有价值。我见过太多Agent项目线上出了事只能靠模型回放日志猜原因因为日志里只记录了“模型调用了某工具”没记录“任务整体处于什么状态”。Poppy草案的做法相当于给每个任务配了一条状态机履历任何时刻都能回答三个问题现在在哪、怎么到这一步的、下一步允许去哪。它还很聪明地把存档内容和动作日志分开。动作日志记录的是执行细节状态事件记录的是任务层面的演进。平时排查用状态事件定位需要深挖时再查动作日志。这个分层隔离极大降低了审计成本。对很多企业来说没有这条可审计的状态链Agent根本过不了安全合规审查。3. 实操视角假设要让Agent办成一件事草案落地长什么样光谈概念没有用我们直接推演一个具体场景。这个例子能比较清楚地展示网页、API、人工客服三条线如何通过草案定义的机制串起来。3.1 一个完整的跨通道办事流程示例假设场景企业内部员工想让个人Agent把一份本地合同上传到外部供应商系统然后发起审批。这个任务听上去简单跑起来却有典型的三段式结构。第一步Agent通过内部API读取合同文件校验文件类型和大小。这一步是纯API操作状态明确、权限清晰。第二步Agent登录供应商网站并上传文件。这一步进入网页通道。Agent先解析页面语义层找到上传控件完成登录和文件上传再等待页面返回上传结果。这里要小心一个常见问题上传完成后页面可能不会跳转只弹出一个提示条。没有语义层支持的Agent很容易误判为失败。第三步Agent发现文件上传成功但页面上没有“发起审批”的按钮。原因可能是当前账号权限不足只能上传不能提交。这是一个典型的“ Agent能力边界外”的场景草案给出的处理方式是不是报错终止而是生成一个迁移结构描述请求人工决策。人工管理员收到这个描述后看到了Agent已经完成的步骤、当前的任务状态、待决策的问题是“是否用管理员账号代办审批发起”然后一键确认。Agent收到人工决策后继续执行把审批状态同步到内部系统最终触发邮件通知。整个流程里Agent、网页系统、API服务、人工管理员之间的状态是连续的没有一次交接需要重看日志。3.2 迁移结构描述的数据格式参考迁移结构描述是草案里的关键机制假设要落地实现我个人会建议先定义一个最小数据格式大概长这样{ task_id: task-42, source_agent_id: agent-01, trigger_reason: permission_denied, task_status: AWAITING_HUMAN, current_state: { site: supplier-portal, upload_result: success, approval_step: blocked }, action_history: [ {action: upload_file, result: ok, timestamp: 2025-01-01T10:00:00Z}, {action: check_approval_button, result: not_found, timestamp: 2025-01-01T10:01:00Z} ], pending_questions: [ {type: approval, question: 是否需要使用管理员账号代为发起审批} ], context_ref: storage://tasks/task-42/context.json, response_format: { type: single_choice, options: [approve_as_admin, skip_approval, cancel_task] } }我建议关注几个点。一是必须有context_ref不要把所有上下文都塞进交接单本身否则大任务会把消息体撑爆。二是action_history只保留结构化动作不要贴原始日志人工真要看细节再按引用去取。三是response_format要明确限制人类的回答格式让Agent能直接消费人工的反馈而不是发一段口语就完事。3.3 落地时最容易踩的几个坑第一把迁移结构描述当成日志来用。有些团队会觉得“反正都是记录过程”直接让Agent把所有中间结果写进交接单。这是错的。迁移结构描述是给下一个执行者看的它需要有决策重点。日志是给人复盘用的两者混在一起会让人工接手时面对一篇流水账。第二网页语义层做成了新的爬虫框架。草案里说的语义层核心是“面向目标的界面描述”不是又一个选择器定位工具。如果实现时只把DOM快照加了一层注释Agent稳定性不会有任何提升。真正的语义层应该回答“这个页面上有哪些操作能力”而不是“这个button在哪个位置”。第三没有给人工交接定义超时和降级策略。Agent发出迁移结构描述后人工可能几小时不回复。任务状态一直挂着后续动作全部堵死。草案目前对超时策略没有强约束落地时必须自己设计超时后是重试提醒、升级交接、还是自动回滚到上一个稳定状态。4. 共识、争议与实验路径草案还很新怎么参与最稳Poppy草案现在还处于公开讨论阶段很多内容没有完全定稿。不过已经能看到一部分共识也能看到几个短期内吵不出结果的争议区。4.1 草案里相对清楚的部分跨通道的状态描述确实到了该统一的时候。无论采用Poppy还是别的草案用一套结构化的状态机把网页操作、API调用、人工交接串起来这个方向几乎没有人反对。可迁移、可恢复、可审计这三个属性已经被广泛认可为个人Agent进入生产环境的基本要求。另一个有共识的点是“人工交接必须结构化”。过去那种“Agent抛报错、人肉看日志”的做法已经完全不适应Agent规模化使用。一个能预测的交接协议比任何模型能力优化都能直接提升任务成功率。4.2 几个还没有答案的争议地带第一个争议是表示层的权限边界。如果Agent能读网站语义层它理论上能理解任何页面的操作能力。那么问题来了哪些页面允许Agent操作哪些操作需要静默授权目前草案里画了一条“操作语义必须显式声明”的线但具体怎么做权限枚举还没有成熟方案。有些站点会担心一旦语言模型很好理解界面网页就等于对Agent全裸。这个顾虑短期内很难消除。第二个争议是存档的隐私边界。状态演化要求记录完整过程但整个执行历史里可能包含身份证号、银行账户、健康信息等敏感数据。写审计日志的时候要不要脱敏在哪个环节脱敏草案目前只在原则层面提到最小化采集工程层的字段级策略还没定义清楚。如果不把这层想清楚很多合规团队不会让草案进入生产环境。第三个争议是任务编排的竞合关系。草案想做任务层的统一描述但它和已有的工作流引擎、RPA配置平台、Agent编排框架之间存在明显的重叠。到底谁应该是宿主谁应该是插件社区还没有统一意见。我个人倾向认为Poppy这类草案更适合做“中间表示”而不是直接做成一个重运行时。4.3 想在现网试水的具体建议如果我的团队现在就要用Poppy草案的思路做改造我会选择渐进式落地而不是等协议完全成熟。第一步在现有Agent系统里增加一个标准状态事件表。不改变执行引擎只把原来零散的动作日志映射到统一状态机上。这一步的成本很低但立刻能得到一个排查问题的利器。第二步挑两个人工介入最频繁的场景定义迁移结构描述。不要把全部场景都覆盖选高频的、痛苦的、出错过的地方做试点。第三步在网页自动化层逐步引入语义描述优先覆盖上线以来最稳定的TOP页面。不需要把整个站点都语义化先把高频路径做干净。这套路径的好处是每一项都不依赖草案最终定稿但每一步都在向草案描述的形态靠近成本最稳。我个人在做这类尝试时的体会是草案带来的最大收益不是某个具体机制而是逼着团队把“任务边界”“交接语义”“状态可见”这几件事重新想清楚。Agent跑得再好如果没人能看懂它到底在做什么这个系统就永远只能停留在演示阶段。最后分享一个小技巧如果你不知道从哪里开始定义迁移结构描述去翻你们客服系统里转人工最高频的几个场景把它们的手工转接单反向结构化草案需要的字段自然就出来了。
实战指南：从原理、代码到调参与应用)
