Agent 要替人办事，业务系统需要一个正式入口

很多团队给业务系统接 Agent，起手式往往很相似。

做一个聊天入口，接一组工具，模型能查订单、改地址、帮用户填表。演示跑通后，下一步就变得很微妙：它该去点现有网页，直接调 API，还是转给企业自己的客服 Agent？用户登录一次后，下一步的授权、会话和确认又该落在哪？

这些问题还没有通行的答案。于是每加一种 Agent，就多一套接入、一套登录状态和一套例外处理。业务方看见的是“又来了一个渠道”，用户感受到的却是同一件事被反复问身份、反复确认、反复丢上下文。

Sierra 这周公布的 Personal Agent Protocol（Poppy）0.1 草案，想补的正是这一层。它不负责让模型更聪明，也不定义“怎么买一件商品”。它试图规定一件更朴素的事：当一个人带着自己的 Agent 去找一家企业办事时，双方怎样发现彼此、建立一次会话、拿到授权，并在网页、API 和对话之间不把这件事弄丢。

这份文档还是草案，写得很明确，0.1 版的任何部分都可能改动，甚至可能出现不兼容变化。所以现在不该把它当成待采购的标准件。更值得拿走的，是它逼业务系统回答的那几个问题。

你缺的可能不是又一个 Agent，而是一张入口地图

Poppy 的结构很像把企业面对 Agent 的入口整理成一张目录。

企业可以在 /.well-known/poppy.json 放一份描述文件，告诉外部 Agent：我提供什么样的登录方式，有没有可用 API，能不能让浏览器加入同一会话，是否有企业自己的对话 Agent。Agent 不必靠页面猜测，也不必为每家公司先学一遍私有规则。

文档里最有用的设计不是这个文件本身，而是“一次会话跨多个渠道”。同一个任务可以先在网页上看退货政策，用户需要用账户时再完成 OAuth 登录，之后转到 API 查库存，必要时继续和企业 Agent 对话。它们仍然是同一件事，而不是三段彼此无关的操作记录。

官方图里的重点不是多了三个入口，而是企业可以用同一套规则决定三个入口各自能做什么。

今天不少接入方案正好反过来。网页自动化是一支团队做的，MCP 是另一支团队做的，客服机器人又归另一个供应商；登录和风控各管各的。功能没少，用户权限却在渠道切换时被悄悄放大或丢失。

如果你的团队正在做这类能力，先别急着把 poppy.json 写进路线图。先画出自己的入口地图。每一种能力都标上三件事：它读什么、它能改什么、它在什么条件下必须停下来等人。

网页、API 和企业 Agent，不该用同一把尺子选

Poppy 给出的三条路，恰好能帮助团队少走一种常见弯路：把所有任务都塞进对话式 Agent。

网站入口适合已有完整流程、但还没有为 Agent 整理 API 的场景。个人 Agent 可以在企业现有页面里完成查询或准备动作。这里最容易失控的是浏览器权限。看见页面不等于可以提交页面；加入一次浏览器会话，也不等于拿到支付、地址、资料下载这些权限。网页可作为兼容层，但高风险动作仍应经过企业侧独立确认。

API 入口适合动作边界已经稳定、调用频率高、结果容易校验的任务。查订单、查库存、创建一个待确认的变更，都比让模型在页面里找按钮更可控。Poppy 草案把 OpenAPI 和 MCP 都列为企业可声明的接口类型，信号很清楚：协议不想替换现有接口，而是想让 Agent 知道接口何时可以被谁使用。

企业 Agent 入口适合规则复杂、需要来回追问的任务，例如保修、换货或异常处理。它的价值不是“更像人”，而是企业可以在对话里保留业务规则、证据链和人工转接。代价也很明确：别把对话当成权限绕过通道。企业 Agent 能说“我可以帮你申请”，不代表它可以默默完成一次不可逆操作。

选择时可以用一个很短的判断式。

动作只有查询、页面流程已经成熟        → 网页可以先接住
动作边界稳定、需要可靠写入或批量调用  → 优先整理 API
任务需要解释规则、补材料和人工协作    → 再考虑企业 Agent

无论走哪条路，只要会改数据、通知他人、扣费或提交申请
都要有企业侧可验证的确认点

这不是技术洁癖。Agent 越会把几步操作串成一步，越需要有人能回答“它到底代表谁，在什么范围内代表，提交动作由谁确认”。

把授权从“登录成功”里拆出来

Poppy 草案里有个容易被忽略的细节。会话一开始可以是未登录的，企业知道这是某个 Agent 为某位用户而来，却不必立刻知道用户的账户身份。任务真的需要账户能力时，再由用户授权；会话令牌是短期的，账户令牌只在企业的令牌端点使用。

这给业务团队一个很好的拆法。不要把“能登录”直接翻译成“可以做所有事”。至少把下面四层分开：

• 识别：这是哪个 Agent，它是否按企业规则声明自己。
• 身份：它当前代表的是哪个已经登录的账户，还是匿名访问者。
• 范围：这次授权只允许读订单，还是允许发起退货、改联系人、请求退款。
• 提交：哪个动作会真正留下外部记录，是否需要用户再看一眼或由人工接手。

协议还要求每家企业看到的用户标识彼此不同，不能从邮箱、电话或姓名推导出来。这个设计不是为了让产品显得更“隐私友好”，而是在提醒实现者：跨企业追踪不应随着 Agent 接入被顺手带进来。

下面这个片段不是可直接上线的配置，只是把草案里的目录思路缩小到工程团队方便讨论的尺度：

{
  "auth": { "issuer": "https://auth.example.com/" },
  "web": { "browser_session_endpoint": "https://example.com/agent-session" },
  "apis": [
    { "type": "openapi", "url": "https://api.example.com/openapi.json" },
    { "type": "mcp", "url": "https://mcp.example.com/mcp" }
  ]
}

真正需要评审的不是字段会不会写，而是每个 endpoint 后面有没有对应的动作分级、过期策略、审计记录和撤销路径。没有这些，协议把入口接得越顺，错误也可能走得越顺。

合作名单能说明问题被很多行业看见了，不能替代任何一家企业的生产可用性承诺。

现在可以做的，不是押注协议

Sierra 的官方公告说，协议将继续通过设计工作坊打磨，并计划发布参考实现。草案里也留下了尚未覆盖的开放议题。今天更适合做准备工作，不适合为了赶概念重构一套成熟业务。

我会建议把准备工作压成一次跨团队评审，而不是开一个“Poppy 项目”。拿出一个用户已经会交给 Agent 的任务，例如查订单、变更预约或处理退货，然后把下面几项填满：

1. 这个任务有哪些只读步骤，哪些步骤会改变状态。
2. 用户登录前后分别能看到什么，授权失效后会怎样收口。
3. 网页、API、对话三条路里，哪一条是主通道，哪一条只是兜底。
4. 用户说“停”或撤销授权后，正在跑的会话、令牌与后台任务如何被切断。
5. 发生争议时，团队能否回放 Agent 提出了什么、系统批准了什么、最终由谁确认。

如果这五项还没有答案，先接哪一种协议都只是把不清楚的业务规则暴露得更快。如果它们已经有答案，那么无论 Poppy 是否成为主流，团队都会得到一套更容易接 API、更容易审计、也更不容易把用户权力交错地方的入口设计。

个人 Agent 进入企业系统，真正的门槛从来不是让模型找到按钮。是企业能不能把“欢迎进来”和“允许替用户做决定”之间那段距离，认真地设计出来。

如果你的业务系统只先开放一条 Agent 入口，你会选网页、API，还是企业 Agent？最难拿捏的那个提交动作又是什么？