回忆 Day 12 的核心理念：一个镜像 + ENABLED_AGENTS + APP_ENV = 任意 agent 组合 × 任意环境。今天把这条链上的每一环讲清：

入口是 load_config()（config.py:291），Day 02 讲过它的 5 步，今天把核心三段真代码逐行读透。先看主流程（裁剪）：

app_env = env or os.environ.get("APP_ENV", "dev")     # ① 当前环境从 APP_ENV 来，默 dev
configs_dir = _find_configs_dir()                     # 向上找 configs/base.yaml
base_path = configs_dir / "base.yaml"
env_path = configs_dir / f"{app_env}.yaml"            # 如 prod.yaml

if not env_path.exists():                             # ② 找不到 profile → 回退 dev（不硬崩）
    log.warning("profile %s.yaml not found ... falling back to dev", app_env)
    env_path = configs_dir / "dev.yaml"

base_data = yaml.safe_load(_expand_env_vars(base_path.read_text(...))) or {}   # ③ 展开 ${VAR} 再解析
env_data  = yaml.safe_load(_expand_env_vars(env_path.read_text(...)))  or {}

merged = _deep_merge(base_data, env_data)             # ④ base 打底，profile 覆盖差异
merged["app_env"] = app_env                           # ⑤ config.py:334 · 强制回填，SSOT
return Config(**merged)                               # ⑥ Pydantic 校验（extra=forbid）

逐步讲：① "当前是哪个环境"只认环境变量 APP_ENV。② 找不到对应 profile 不报错崩掉，而是打个 warning 退回 dev.yaml——容错。③ 读文件后先做 ${VAR} 环境变量展开、再交给 yaml 解析（见下 L03）。④ 用 _deep_merge 把 base 和 profile 合并。⑤ 合并后强制把 app_env 覆盖成入参值。⑥ 最后过一遍 Pydantic 校验。

核心是那个"逐条比对"的会计——_deep_merge（config.py:255），只有 8 行但很关键：

def _deep_merge(base: dict, override: dict) -> dict:
    """deep merge · dict 递归 · list / scalar 走 override 覆盖."""
    result = dict(base)
    for key, value in override.items():
        if (key in result
                and isinstance(result[key], dict)
                and isinstance(value, dict)):
            result[key] = _deep_merge(result[key], value)   # 两边都是 dict → 递归往下合
        else:
            result[key] = value                              # 否则 override 直接覆盖
    return result

大白话：它递归地比对两个字典。遇到"两边同名、且都是字典"的键，就钻进去继续逐层合并（而不是整块替换）；遇到标量或列表，就用 override 的值直接盖掉。这意味着 profile 里只要写 database.arch_compliance.host 一个字段，base 里 database 下的其它字段（port、user、其它 pool）全部原样保留——这就是"只写差异"的技术底座。

光看 _deep_merge 的代码不够直观。直接拿仓库里三个真实文件跑一遍合并，你就彻底懂了。先看 base.yaml 的 database 段（configs/base.yaml:8-27）：

database:
  arch_compliance:
    host: ${MYSQL_HOST:-mysql}          # ${VAR:-默认值} 形式
    port: 3306
    user: ${MYSQL_USER:-app}
    password: ${MYSQL_PASSWORD:-app_local}
    database: ${MYSQL_DATABASE:-arch_compliance}
    autocommit: true

这是"标准做法"：password 不写死，用 ${MYSQL_PASSWORD:-app_local} 从环境变量取（没设就用本地默认）。_expand_env_vars（config.py:239）就是干这个展开的，正则只认大写下划线的变量名（config.py:236 的 _VAR_PATTERN）。

再看 dev.yaml 只写了 database 的差异部分（configs/dev.yaml:4-10）：

database:
  arch_compliance:
    host: bmdevdb.czmaueomanj2.ap-northeast-1.rds.amazonaws.com
    port: 3306
    user: dev
    password: 27gErtSiE5jy#NxCUeLQ     # ← 明文密码，违反 base 自己的规范！
    database: obelisk

合并完，整个结果交给 Config(**merged) 做 Pydantic 校验。注意每个配置模型都写了 model_config = ConfigDict(extra="forbid")（如 config.py:218）：

class Config(BaseModel):
    model_config = ConfigDict(extra="forbid")   # ← 多写/拼错一个 key 就启动报错
    app_env: str = "dev"
    database: DatabaseConfig = Field(default_factory=DatabaseConfig)
    redis: RedisConfig = ...
    cost: CostConfig = ...
    # ...

根目录 Dockerfile 用多阶段构建（multi-stage） + uv。核心思想：把重的依赖装在 builder 阶段，运行镜像只带必要的东西。先看 builder 的关键顺序（Dockerfile:15-59）：

FROM python:3.12-slim AS builder
COPY --from=ghcr.io/astral-sh/uv:0.11.13 /uv /uvx /bin/    # 装 uv
ENV UV_LINK_MODE=copy UV_COMPILE_BYTECODE=1 UV_PROJECT_ENVIRONMENT=/opt/venv
WORKDIR /app

# ① 先只 copy lock + 各包的 pyproject.toml（不含源码）
COPY pyproject.toml uv.lock ./
COPY packages/ai-trust-toolkit/pyproject.toml packages/ai-trust-toolkit/
# ... 20 多个 app/包的 pyproject.toml 一个个 COPY ...

# ② 纯依赖安装（无源码）→ 这一层能被缓存
RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --frozen --no-install-workspace --all-extras --all-packages   # Dockerfile:59

# ③ 再 copy 全部源码 + configs + docs + examples
COPY packages/ packages/
COPY apps/ apps/
COPY configs/ configs/

# ④ 第二次 sync：editable 装 workspace 自身
RUN uv sync --frozen --all-extras --all-packages          # Dockerfile:74

逐步讲：① 先只拷"依赖清单"（各 pyproject.toml + uv.lock），不拷源码。② 第一次 uv sync --no-install-workspace 只装第三方依赖。③ 这之后才拷源码。④ 第二次 sync 把本仓 workspace 的包 editable 装进去。

再看 runtime 阶段——只拿 builder 的成品（Dockerfile:77-113）：

FROM python:3.12-slim AS runtime
RUN apt-get install -y git ...                            # 装 git（coding agent 用）
RUN groupadd -r app && useradd -r -g app ... app          # ① 非 root 用户
COPY --from=builder /opt/venv /opt/venv                   # ② 只拷 venv + 源码
COPY --from=builder --chown=app:app /app/apps /app/apps
USER app                                                  # 切非 root
HEALTHCHECK --interval=30s ... CMD python -c "... /healthz ... == 200"   # ③ 健康检查
CMD ["python", "-m", "uvicorn", "gov_agents_server.main:app",
     "--host", "0.0.0.0", "--port", "8080", "--workers", "2", "--proxy-headers"]

runtime 只做三件事：① 建一个非 root 用户 app（安全，符合 K8s runAsNonRoot）；② 从 builder COPY --from=builder 拿现成的 venv 和源码——builder 那堆构建缓存、编译产物一概不搬；③ 挂 HEALTHCHECK 打 /healthz，启动 uvicorn。

Day 02 提过。docker-compose.yml 实际两个服务（README 说四个是漂移）：

services:
  redis:                        # Working Memory 的 checkpointer 后端
    image: redis:7-alpine
    ports: ["6379:6379"]
    healthcheck: ...
  platform:
    build: .                    # 用根 Dockerfile 构建
    ports: ["8080:8080"]
    depends_on:
      redis: { condition: service_healthy }   # 等 redis 健康才起
    environment:
      APP_ENV: ${APP_ENV:-dev}                 # ← 打通 config profile（L02）
      ENABLED_AGENTS: sre-rca,risk-reviewer,... # 选 agent 组合
      REDIS_URL: redis://redis:6379
      # 一堆 ${VAR:-} 占位透传 DB/Anthropic/Lark

关键：APP_ENV: ${APP_ENV:-dev} 把 compose 和 L02 的配置系统打通——APP_ENV=prod docker compose up 就切生产配置，同一份 compose 文件。ENABLED_AGENTS 则接上 Day 12 的"一个镜像挂任意 agent 组合"。

生产部署清单在 deploy/k8s/，用 Kustomize 组织——和配置 profile 一样的"base + overlay 覆盖"思想：

• base/：通用的 Deployment / Service / ConfigMap 等。
• overlays/<env>/：每个环境的差异（副本数、资源、镜像 tag、环境专属配置）叠加在 base 上。

deploy/grafana/ 还有现成的监控面板（cache-dashboard.json）——对接 Day 11 的 Prometheus 指标。

这就是 Day 05 讲的"一个 agent 有 server.py（给平台挂）和 main.py（独立跑）两个入口"的部署对应。Dockerfile 默认 CMD（Dockerfile:111）跑的就是形态①；ENABLED_AGENTS 未设=挂全部，写非法名快速失败报错。

最后强调一个部署可靠性的基石——那个 890KB 的 uv.lock（仓库里真实大小）。docs/deployment.md 有句话点透了它的本质：

它锁死了几百个包的精确版本 + 哈希。所以你本地、同事机器、CI、生产镜像装出来的东西字节级一致——彻底消灭"在我机器上是好的"。这也是为什么 Dockerfile 用 --frozen（:59/74，严格按 lock 装）、CI 有专门的 gate 校验 lock 与 BOM 一致（Day 18）。

✋ 动手：读今天走读过的真代码

# 1. 配置深合并三段核心
sed -n '236,267p' packages/ai-trust-toolkit/src/ai_trust_toolkit/config.py   # _expand_env_vars + _deep_merge
sed -n '291,339p' packages/ai-trust-toolkit/src/ai_trust_toolkit/config.py   # load_config

# 2. 三个真实 profile（看深合并 + secret 反面教材）
cat configs/base.yaml
cat configs/dev.yaml
cat configs/prod.yaml

# 3. 多阶段 Dockerfile
cat Dockerfile

# 4. compose 两个服务
cat docker-compose.yml

# 5. 本地起全栈（有 Docker 的话）
APP_ENV=dev docker compose up -d
curl localhost:8080/healthz