[Discussion] AI Gateway 与业务操作治理控制面应该如何分工？

[niejingchuan]

背景

Higress 已经能够统一管理 LLM API、MCP Server 和 Agent API，并提供认证、路由、限流、审计与可观测能力。

但当 Agent 开始操作订单、库存、退款、员工等真实业务系统时，还需要回答另一组问题：

• 哪些业务能力可以暴露给 Agent？
• 调用是否必须绑定可信的真实业务主体？
• 哪些操作属于高风险或需要人工审批？
• 最终业务权限应该由哪一层判断？

我目前倾向于将职责分为三层：

1. AI Gateway：负责协议接入、路由、认证、流量控制和通用安全。
2. Agent-facing 业务治理层：负责能力暴露、风险、主体要求、审批意图、审计和执行追踪。
3. 业务系统：负责用户权限、租户隔离、实时业务规则和最终授权。

Gateway 管连接与流量；Agent-facing 治理层管能力触达和执行过程；业务系统保留最终 Authority。

想向 Higress 社区请教

1. 这类 Agent-facing 业务治理能力，更适合由 Higress 核心、Wasm 插件，还是外部控制面承担？
2. 如果 OpenAPI 或 MCP Tool 元数据包含风险、主体、审批和审计声明，Higress 是否适合保留或消费这些信息？
3. 更合理的集成方式是 Wasm 插件、外部策略服务，还是独立控制面与 Higress 联动？
4. Higress 的职责边界应停在哪里，才能支持 Agent 治理，同时不演变成业务权限系统或审批工作流引擎？

相关实践

我正在维护开放、实现中立的能力声明契约项目 ACC，以及用于验证相关思路的开源参考实现 BailingHub：

• ACC: https://github.com/agent-capability/agent-capability-contract
• BailingHub: https://github.com/bailinghub/bailinghub

这里不是请求 Higress 直接采用某个项目，也不是提交具体功能需求，而是希望先与社区讨论 AI Gateway 和业务治理控制面之间更合理的职责边界，并了解是否已有相近设计或扩展方向。