控制平面

控制平面与数据平面的分层架构最早源于网络设备设计，控制平面负责决策与协调，数据平面负责实际执行

该插件中把工具勾选上即意味着授权 AI 自主调用这些能力，提供显式的边界控制

在五决策（租户模型、隔离、扩展、控制平面、计量）框架下，当大型企业客户要求独立隔离环境、数据驻留特定区域、通过自有身份提供商登录时，可以只需一次新部署而无需重写应用。

控制平面与应用平面分离是云原生架构的核心模式之一：控制平面负责租户的创建、配置、套餐变更、隔离环境开通、区域路由、计费关联等管理；应用平面负责处理业务请求。

控制平面通常维护一张租户目录（tenant registry），记录每个租户的路由信息（如数据库连接串、区域、身份提供商配置），应用平面在请求入口处查询该目录完成路由。

控制平面通常依赖认证、数据库、负载均衡等多个组件，任一环节出现问题都可能导致整个管理界面不可用，而计算节点由于独立运行反而表现为在线。

跨租户攻击往往发生在控制平面与数据平面之间的权限校验不一致处。

分层网络的扩展性究竟受限于拓扑本身还是控制平面的实现，原始HN帖子未给出结论。

在企业软件语境中，控制平面通常指集中管理配置、权限、策略、审计和成本的统一界面或服务层。

控制平面的价值随智能体系统复杂度上升而显现。

该控制平面设计只解决控制问题，不能证明一家公司可以自行运转，人类仍负责设定方向并在需要时介入。

控制平面应在执行前依次完成Schema验证、权限检查、幂等与重试限制、持久化状态日志，最后才触达外部系统或API。

生产环境中应将推理与执行权限分离：模型只提出动作请求，由确定性的应用逻辑验证输入、检查权限、记录结果。

控制平面通过workflow_dispatch启动工作流，这是‘协调者永远无法读取代码’规则得以实现的技术支点。

控制平面铸造per-run token，基于run id和过期时间的HMAC签名，有效期30分钟，仅限单次运行。

作者从一条规则出发设计系统：协调Agent的服务永远不应能读取代码。

该系统由两个组件组成：控制平面负责管理错误信息、配置和运行历史；Runner是用户自己的GitHub Actions运行器，持有代码和AI密钥。

控制平面作为GitHub App仅拥有Metadata: read和Actions: read & write两个权限，没有Contents权限，无法克隆仓库或读取文件。

当前基准测试中，召回平面已被广泛基准测试，而控制平面在面对实际部署的生产系统时覆盖远远不足。

召回平面对应读路径，衡量指标通常是召回率、精度和延迟；控制平面对应写路径与生命周期管理，包括新增、取代、撤销、过期、清除事实及对过期状态的传播和确认机制。