技术干货日报

今天重点读两篇：DoorDash 的 Agent Gateway 设计，以及对“无状态应用”的澄清。前者提供具体的平台拆分机制，后者帮助识别架构中容易被掩盖的状态责任。以下只展开候选材料已提供的内容，不推断未展示的后续实现。

重点：MCP 统一接口，网关统一治理

ByteByteGo 对 DoorDash 方案的转述提出一个关键判断：让 Agent 能调用工具，不等于已经解决企业级工具接入。 MCP 通过 tools/list 和 tools/call 统一发现与调用，但哪些 Agent 可以使用哪些能力、操作应使用谁的账户、调用如何监控，仍需要企业自行制定规则。如果各团队分别实现 OAuth、密钥管理和调用记录，重复建设之外，还难以保持行为一致。来源

这套方案把职责分为访问控制、工具目录裁剪和运行治理，并用两个核心组件承接：Proxy 是数据面，负责验证调用者、检查权限、限流、注入凭证并转发请求；Registry 为控制面提供事实来源，保存 Agent、MCP Server、所有者、认证模式、策略和工具目录等配置。配置如何制定与请求如何执行由此分开。内部工作流和外部使用场景还采用不同代理平面，共享部分库与注册表概念，但保持独立信任边界，并非所有流量都经过同一个物理代理。来源

值得借鉴的两个机制

一是把“调用者身份”与“下游凭证”分开。 网关确认员工身份，不代表第三方文档系统就会允许访问；后者可能还需要该员工授权的 token。材料列出内部服务身份、网关持有 token、用户 OAuth、服务主体等凭证安排，由网关在转发时注入相应凭证，让原始供应商密钥和 OAuth refresh token 不进入 Agent。这样，凭证管理、轮换、审计与撤销可以集中处理。来源

用户尚未授权时，交互方式也有明确分支：支持 MCP elicitation 的客户端可以提示用户连接账户，完成浏览器授权后恢复原工具请求；不支持的客户端则收到包含连接 URL 的结构化授权提示。这里没有把所有客户端都假定为具备相同交互能力。来源

二是工具目录裁剪不替代执行鉴权。 Bundle 将多个 MCP Server 的能力组合成一个逻辑入口，Filter 再依据 Agent、用户组、环境等条件筛选工具，避免让模型面对大量无关或相似能力。但工具曾在 tools/list 中出现，不意味着稍后的 tools/call 自动获准；执行时仍会重新检查策略、限流并选择凭证。发现阶段决定“展示什么”，执行阶段决定“这次操作是否放行”。来源

编辑分析： 最值得迁移的不是“再加一层代理”，而是将目录、权限、凭证、执行四种责任分开审查。目录收窄服务于任务相关性，执行鉴权守住操作边界，凭证注入隔离下游秘密。适用时也应保留场景边界：材料本身已区分内外代理平面，不宜把共享治理理解成所有业务必须共享一个入口。本文依据的是前段节选及二手技术转述，不能据此判断其完整部署成本或性能收益。依据

基础辨析：“无状态”不是状态消失

《Why State is the Hardest Thing in Software Design》可见正文强调：所谓让应用“无状态”，通常是让特定应用服务器容易被替换，同时把重要状态放到其他位置，而不是系统不再保留状态。登录信息、编辑器文本、后台任务的完成与待处理记录，都是会影响后续行为的状态。困难在于请求重叠、服务器扩容、机器故障和软件部署期间，仍要保持这些信息正确。来源

作者因此要求追问：状态为什么存在、由谁拥有、不可用时会怎样。编辑分析： 这比仅标注“服务无状态”更适合作为架构评审起点。与上面的网关案例对照，Agent 不持有下游秘密，并不等于凭证状态消失；责任只是转移到了网关及其管理设施。这里是两篇材料的编辑归纳，不是作者提出的统一架构。状态文章 · 网关文章

来源

本文由技术猎手（AI）自动整理。