大量团队已经自建了 AI Agent，但它们回答产品问题通常靠 RAG 拉帮助中心文档——文档滞后于产品，且把「读文章再自己琢磨怎么用」的活推回给用户。Frigade 9 月 8 日推出的 Assist API 想换一种方式：让 Agent「用」产品，而不是「读」文档。
底层机制通俗拆解
Frigade 用一个浏览器 Agent 以真实用户权限登录客户产品，跑通真实 workflow，构建「产品当前怎么运作、功能如何相连」的模型；每次发版后重学，保证知识是线上版本而非旧文档。企业把它注册为一个 tool，自己的 Agent 一次 tool call 即可拿到「基于产品今天行为」的答案，或发起页面内分步引导（在当前页面高亮下一步）。
本次核心优化点
一是解决「双 Agent 竞争」——用户只跟自己已有的 Agent 对话，Frigade 作为知识工具而非第二个助手，所有回合仍路由回企业自己的 Agent；二是支持团队可审阅对话、纠错、调整 Agent 知识，无需工程介入，把「Agent 知道什么」变成支持资产而非代码资产；三是框架无关，兼容 Vercel AI SDK，企业可自托管并自带 LLM key，数据不出域；四是权限随用户，Agent 只看该用户能看的内容。
技术取舍与固有局限
一是它学的是「界面行为」，对后端逻辑、权限策略等界面不可见部分无能为力；二是依赖产品界面稳定，UI 大改需重学；三是它补的是「产品知识」而非「任务编排」，复杂跨系统流程仍要别的上层 Agent 统筹。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
同类方案对比
与「文档 RAG」「客服专用 Agent（如 Fin）」相比，Frigade 用「让 Agent 自己用产品」替代「读人写文档」，并把知识做成可编辑的支持资产；与「再买一个助手」相比，它选择做工具的工具的定位，规避了用户面对两个聊天框不知找谁的尴尬。
开发者落地适配建议与踩坑提醒
若团队已自建 Agent 且苦于文档滞后、双助手分流，Assist API 这类「知识注入工具」值得试点；落地前先明确「哪些流程可被浏览器 Agent 跑通」「权限边界划在哪」，并把「Agent 知道什么」交给支持团队维护而非写死在 prompt 里。不要指望它替代完整的 Agent 编排框架，它解决的是「数据入口与产品语境」而非「任务闭环」。