宣传语把问题说简单了

Agent-net 把 Webagent 描述为一种能把网站变成面向公众业务代理的开源 Go harness。这个说法抓住了市场想要的结果，却掩盖了实现条件：当前框架并不是读取任意网站页面、自动理解流程，再替企业完成全部操作，而是让企业在声明式 JSON 规格中，为一个代理的多个功能槽位选择提供者，然后运行 `webagent serve`。

代理的核心是一个 Brain，也就是大模型加指令，周围则是动作、检索、渠道等可插拔能力。项目把这些能力抽象为服务提供者接口，提供者通过注册表接入，扩展方不需要分叉核心代码。这个设计把“做一个代理”从一次性的编排代码，改成了选择实现、替换适配器和遵守接口契约的问题。

真正的架构判断在 action.Guard

Webagent 最关键的取舍，不是支持多少模型，而是把工具调用放到了一个模型无法绕过的执行管线里。无论工具来自动作提供者，还是由宿主注入，都会先被 `action.Guard` 包装，动作真正执行前必须经过选定的防护机制。模型可以提出调用请求，但不能直接跳过这层代码边界。

这和“在系统提示词里提醒模型不要做危险操作”是两种不同的安全假设。提示词依赖模型是否正确理解并持续遵守规则，Guard 则把检查点放在动作落地之前。材料引用的研究结论也指向同一问题：在模型能力相同的情况下，架构选择可能带来约 85% 对 50% 的任务成功率差距。这里的成功不只是模型会不会回答，而是整个代理能否在工具、权限和失败路径共同存在时稳定完成任务。

从 MCP 服务开始，而不是从浏览器开始

目前 Webagent 最现实的接入路径，是把已有 MCP 服务包装成可对外工作的业务代理。MCP 动作提供者通过 Streamable HTTP 连接服务，支持 JSON 和 SSE，并可使用 bearer token 或 API key 鉴权。构建阶段会完成握手，把实际工具交给代理，同时让 `validate` 报告真实的工具数量，这比只在配置文件里声明“理论上有这些工具”更接近可检查的部署流程。

项目还提供 Slack、WhatsApp 和 HTTP 等渠道适配器。Slack 与 WhatsApp 会校验入站 webhook 签名、立即确认请求、忽略代理自己的消息，并对重试投递去重。密钥也不直接写进规格文件，任何以 `Secret` 结尾的配置键都会在构建时通过选定的 vault 解析，解析失败会阻止渠道启动。这些细节说明，Webagent 已经在处理真实集成中的边界问题，但它们不等于任意网站都能被自动接管。

能跑通示例，不等于闭环已经完成

Webagent 的两个示例，`zomato.json` 和 `bakery.json`，使用不需要凭据或网络的 echo brain 与离线演示动作提供者，因此可以直接运行 `validate` 和 `serve`。这对框架开发很有价值：团队可以先验证规格解析、提供者装配、工具护栏和渠道流程，而不必先配置真实模型或外部服务。但它证明的是脚手架和本地执行路径可用，不是实时模型、真实工具链和全部通信渠道已经准备好。

项目当前标记为 v0。浏览器动作提供者、OAuth 保护的 MCP、OpenTelemetry 导出，以及 AgentNet 的身份与计费层仍列为未完成；部分示例渠道也仍是 stub。对准备试用的团队，合理判断应是先把已有 MCP 服务接入，逐项检查 `validate` 输出、Guard 覆盖范围、密钥解析、webhook 重试和失败行为，再决定是否让代理接触生产动作。Webagent 的价值正在于把这些问题显式化，而不是替团队取消这些问题。