把 Agent 做成基础设施 —— 多业务共享 Agent 基建的工程实践

话题概述:
当一个 Agent 产品跑通后，第二、第三、第四个业务也想要 Agent 能力。每个业务独立建设意味着重复造轮子——但 Agent 不是传统 Web 服务，它的执行是有状态的长流程、工具调用需要跨前后端协作、上下文是和模型行为耦合的动态结构。把 Agent 做成可共享的基础设施，工程挑战远不止"抽公共代码"。
这次分享将还原我们从单一 Agent 产品演进到多业务共享基建的完整过程：为什么需要一个管理平台让不同角色（产品、研发、领域专家、运营）各自协作；如何设计一个可中断恢复的执行引擎让多种业务模式在同一套 Loop 上运行；前后端之间需要什么样的协议来支撑组件工具、前端工具、Artifact 这些 Agent 独有的交互模式；以及当所有这些共享同一个 LLM 上下文时会遇到什么问题。所有内容来自生产环境的真实决策和踩坑。

话题亮点：
1. Agent 产品的生命周期不止是写代码，所以基础设施不止是执行引擎 —— Agent 需要有领域知识的专家持续优化 Skill 和 Prompt，需要运营监控质量和成本，需要产品配置行为策略。我们如何设计一个多角色协作的管理平台，让"配置一个 Agent"这件事不全堵在研发排期里——以及为什么这件事比听起来更难（权限模型、配置灰度、效果可预览）。
2. Agent 执行是有状态的长流程，"调用一次等结果"的模型用不了—— AgentLoop 中途可能需要等用户在前端确认一个组件、等浏览器执行一段代码、等一个异步工具返回结果。我们如何借助 Redis 实现任意节点的中断和恢复，以及这套中断恢复架构如何让不同业务模式（纯后台、人机协同、多轮审批）跑在同一个引擎上。
3. Agent 的前后端协议是一个全新品类，不是 REST 也不是 WebSocket —— LLM 输出"组件标签"后后端要 hold 住执行流等前端返回、前端工具需要在浏览器执行后把结果回传、产物需要自动判断是否生成 Artifact 并路由到正确的渲染器。这套协议在 Agent 出现之前不存在，我们从零设计了它，并且踩了很多"看起来合理但实际不行"的坑。
4. 业务方接入基建不应该交出自己的技术体系—— 每个业务有自己的鉴权、计费、水印、安全校验。我们用 Hook 架构把这些控制权交还业务方，让他们在不碰平台代码的前提下完成接入。重点分享为什么是 Hook 而不是配置、粒度怎么划分、以及 Hook 设计中"平台收权 vs 业务自治"的权衡。