用途：当新的智能体引擎或 LLM 提供商需要接入 AWF 且不清楚如何配置时使用本技能。AWF 有两条根本不同的集成路径，选错是常见困惑来源（例如某引擎的 token-usage.jsonl 为空）。
第一步：判断引擎如何访问其 LLM 后端。看它是直接调用提供商 API（自有 base URL 与认证），还是可配置为经 AWF 的 api-proxy sidecar 路由。sidecar 始终启用，--enable-api-proxy 已废弃并被忽略。其提供商端口为 http://172.30.0.30:10000（OpenAI）、:10001（Anthropic）、:10002（Copilot）、:10003（Gemini）、:10004（Vertex AI）。若引擎支持指向这些端口（如 OPENAI_BASE_URL、ANTHROPIC_BASE_URL 被改写）则走路径 A；若始终调用自身硬编码端点（如 Cursor CLI 直连 api2.cursor.sh / api3.cursor.sh）或自行管理凭据，则走路径 B。不确定时用 --keep-containers 运行一次，检查 docker exec awf-squid cat /var/log/squid/access.log 看实际访问的主机与流量走向。
路径 A（代理型提供商，凭据由 api-proxy 注入）：适合希望 AWF 持有 API key/OIDC token 并注入、使密钥不进入智能体容器的场景。参考 containers/api-proxy/providers/ADDING-A-PROVIDER.md，创建 <name>.js 实现 ProviderAdapter 接口并在 index.js 注册；把端口加入 src/config/sandbox-network-policy.json，扩展 src/config/network-policy.ts 的 NetworkPolicy 形状与校验及 src/types/ports.ts 的兼容映射，加入 Dockerfile EXPOSE；在 src/services/api-proxy-env-config.ts 加入凭据，并在 src/services/agent-environment/excluded-vars.ts 中显式排除，切勿通用转发凭据；将上游域名加入调用方配置的 --allow-domains 白名单；新认证模式需记录到 docs/auth-matrix.md；编写适配器单元测试并运行 cd containers/api-proxy && npm test -- providers/<name>.test.js。
路径 B（直连 API 引擎，无需代理适配器）：适合引擎直连自有 API 且自行管理凭据、或无法经 AWF 注入凭据的情况。只需将所需域名加入白名单，例如 awf --allow-domains api2.cursor.sh,api3.cursor.sh -- cursor-agent ...，或在配置文件的 network.allowDomains 中设置。若引擎需要 API key，则无法获得 api-proxy 的凭据隔离，应通过适合调用方的最小权限机制传递，不要用 sensitiveAllowedDomains 传密钥（该设置仅在日志与审计中脱敏）。注意：流量不经 sidecar，token-usage.jsonl 与 token 追踪指标将为空，依赖代理遥测的检查需排除此类引擎。用 --keep-containers 与 Squid 访问日志确认域名正确并迭代白名单。
限制：资料未提供各提供商的具体认证细节、价格或平台支持范围；AWF 本身不硬编码各提供商域名。