企业官网建设流程全解析

1. 项目概述：当企业开始批量部署 Agent，控制面就不再是“可选项”

最近三个月，我帮六家不同行业的客户落地 AI Agent 项目——从制造业的设备故障诊断助手，到金融公司的合规文档自动审查流，再到教育机构的个性化学习路径生成器。他们有个共同点：前期用 LangChain 或 LlamaIndex 快速搭出 PoC，跑通一个流程很兴奋；但一旦要上生产环境、接入内部系统、支持 50+ 员工日常使用、每周迭代 3~5 个新技能，所有人几乎在同一周内发来同一条消息：“Agent 开始乱跳、提示词失效、调用超时没人管、日志查不到谁干的、回滚一个插件全服务挂了……我们是不是该换个框架？”

这就是标题里“Harness 不只是管好模型”的真实语境。Harness 在这里不是指某个具体开源库（虽然名字撞了），而是指企业级 Agent 系统中那个看不见、摸不着，但一旦缺失就会让整个智能体集群陷入混沌的稳定控制面（Control Plane）。它不直接参与推理，不生成一句话，不画一张图，但它决定：哪个 Agent 能访问财务数据库、谁修改了核心提示词、某次失败调用是模型崩了还是权限没配、新上线的“合同比对 Skill”是否已通过沙箱安全扫描、凌晨三点告警的 token 超限是单个用户刷爆还是被恶意探测……

关键词 “Harness”、“Agent”、“控制面” 组合在一起，指向的不是一个工具安装教程，而是一套工程化治理逻辑。它解决的不是“能不能跑”，而是“能不能稳、能不能审、能不能扩、能不能退”。尤其在当前 deepseek harness、hermes agent、claude agent skills 等各类 Agent 框架百花齐放的阶段，企业真正卡脖子的，从来不是选哪个 LLM，而是如何让上百个异构 Agent 在同一套规则下协同、受控、可溯、可治。我见过太多团队把 80% 时间花在写 Skill，却用 Excel 表格手动管理 27 个 Agent 的版本、权限和依赖关系——这不是开发，这是高危手工运维。

这篇文章不讲怎么用 Harness 安装插件，也不教 deepseek harness linux 下怎么编译（那些文档里都有）；我要拆解的是：为什么企业必须把“控制面”作为独立架构层来设计？它到底要管什么？哪些能力是“稳定”的硬门槛？以及——最关键的是，一个工程师今天就能动手搭建的最小可行控制面长什么样。如果你正在评估 agent 框架、规划 AI 工程团队、或已被线上 Agent 的飘忽行为折磨得睡不着觉，这篇就是为你写的。

2. 控制面的本质：它不是调度器，而是 Agent 的“操作系统内核”

2.1 为什么不能把控制面塞进现有框架里？

很多团队的第一反应是：“LangChain 有 callbacks，LlamaIndex 有 event hooks，我们加个中间件不就完事了？” 我试过。去年给一家保险科技公司做 POC，他们在 LangChain Chain 上打了 14 个装饰器：记录输入输出、校验 token 用量、拦截敏感字段、注入审计 ID、捕获异常并上报……代码越写越厚，最后发现一个问题：当一个 Agent 同时调用三个 Skill（比如先查保单、再算保费、最后生成 PDF），这三个 Skill 可能分属不同模块、不同线程、甚至不同微服务。LangChain 的 callback 是链式串行的，它根本不知道这三个动作属于同一个业务会话（Session）。结果就是：日志里出现三条孤立记录，审计系统看到的是“张三查了保单”、“未知用户算了保费”、“系统自动生成了 PDF”——完全无法关联。

这就是控制面与应用层框架的根本区别：控制面必须在更底层介入，它要感知和管理的是 Agent 的“生命周期”与“上下文主权”，而不是某一次函数调用。类比一下，LangChain 是应用程序，而控制面是操作系统内核。你不会在 Word 里实现内存分页、进程调度、文件权限检查——这些必须由 OS 提供统一抽象。同样，Agent 的身份认证、资源配额、执行沙箱、跨 Skill 上下文传递，也不能靠每个 Skill 自己去实现一套。否则，就像让每个 App 自己管理内存，迟早 OOM。

提示：判断一个方案是否具备控制面能力，就看它能否回答这四个问题：① 这次执行是谁发起的？（身份溯源）② 它被允许做什么？（策略执行）③ 它用了多少资源？（计量计费）④ 如果它出错了，怎么精准回滚而不影响其他 Agent？（原子性保障）

2.2 企业级控制面的四大刚性能力域

基于过去两年落地的 12 个 Agent 生产系统，我把控制面的核心能力收敛为四个不可妥协的领域。少一个，就不是企业级：

第一，统一身份与策略中心（Identity & Policy Hub）
不是简单加个 JWT 验证。它必须支持：

• 多粒度主体识别：区分“人类用户”（如销售总监王磊）、“机器用户”（如 CRM 同步 Agent）、“临时会话”（如网页聊天窗口生成的匿名 Session ID）；
• 动态策略引擎：策略不是静态 JSON，而是可执行规则。例如：“财务类 Skill 只允许在工作日 9:00-18:00 调用，且单次请求不得包含超过 3 个身份证号字段”——这种规则需要实时解析 SQL-like 表达式，并在 Skill 执行前拦截；
• 策略继承与覆盖：部门级策略（如“所有销售部 Agent 禁止访问 HR 数据库”）可被个人策略（如“销售总监王磊特批访问”）按优先级覆盖，且留痕。

第二，执行环境隔离与沙箱（Execution Isolation & Sandbox）
“agent anywhere” 的愿景背后是巨大风险。控制面必须确保：

• 网络层面隔离：Skill A 访问内网 MySQL，Skill B 调用外网天气 API，两者网络策略必须物理隔离，不能共用一个 outbound proxy；
• 资源硬限：CPU/内存/网络带宽/LLM token 用量，全部可设硬上限（hard limit），而非软警告。实测发现，当一个 Skill 因 bug 进入死循环，软限只会 log 告警，而硬限能直接 kill 进程；
• 文件系统视图隔离：每个 Skill 只能看到自己被授权的目录（如/skills/invoice_parser/data/），且该目录在容器内挂载为只读，防止 Skill 意外改写共享配置。

第三，全链路可观测性（End-to-End Observability）
不是堆 Prometheus + Grafana。企业需要的是：

• 跨 Skill 追踪 ID（TraceID）：从用户点击“生成报价单”按钮开始，到最终 PDF 生成，所有中间 Skill 调用、LLM 请求、数据库查询，必须共享同一个 TraceID，并在 Jaeger 中呈现完整拓扑；
• 结构化日志 Schema：日志不是自由文本。每条日志必须包含agent_id,skill_id,session_id,input_hash,output_truncated,llm_cost_usd,error_code字段，方便 ES 聚合分析；
• 决策快照（Decision Snapshot）：每次 Skill 执行前，控制面自动保存其输入、所用提示词版本、模型参数、策略匹配结果。当用户投诉“为什么给我推荐了错误产品？”，回放快照即可复现当时决策依据。

第四，原子化部署与回滚（Atomic Deployment & Rollback）
“deepseek harness 代码回退”、“agent execution terminated due to error” 这类热搜词，本质是缺乏原子性。控制面必须做到：

• 声明式配置驱动：Agent 的定义（含 Skill 列表、权限、配额）用 YAML 声明，GitOps 流水线提交即生效；
• 双写+灰度发布：新版本 Skill 上线时，控制面同时加载新旧两版，将 5% 流量导给新版，监控 error rate 和 latency，达标后全量切换；
• 秒级回滚：回滚不是重启服务，而是将流量切回旧版镜像，且旧版状态（如缓存、连接池）保持热备，RTO < 2 秒。

这四个能力域，任何一个都无法用现有 Agent 框架的插件机制补全。它们需要独立进程、专用存储、专用 API，构成真正的控制平面。

3. 构建最小可行控制面：从零开始的 7 天实践路线

3.1 第一天：定义你的控制面边界（别一上来就写代码）

很多人失败在第一步：试图用一个“超级框架”替代所有。这是误区。控制面的价值在于解耦，不是大一统。我建议用“洋葱模型”划定边界：

• 最内层（Agent Core）：保留你熟悉的 LangChain/LlamaIndex。它只负责 Skill 编排、LLM 调用、基础 RAG。这一层严禁任何控制逻辑侵入。
• 中间层（Control Plane）：独立服务，提供 4 个核心 API：/v1/authz（鉴权）、/v1/sandbox（启动隔离环境）、/v1/trace（注入追踪）、/v1/deploy（部署管理）。所有 Agent Core 的请求，必须经此层代理。
• 最外层（Orchestrator）：K8s Operator 或轻量级 CLI 工具，负责将 Git 仓库中的 YAML 配置同步到 Control Plane 的数据库。

第一天的任务，就是画出你系统的洋葱图。明确：哪些能力必须由 Control Plane 提供（如“所有 Skill 调用数据库前必须查策略”），哪些可以留在 Agent Core（如“用 ChromaDB 做向量检索”）。我见过最成功的案例，是某银行把 Control Plane 做成一个只有 3 个 API 的极简服务，其余全部交给 K8s 原生能力（NetworkPolicy 做网络隔离，ResourceQuota 做资源限制），反而最稳。

3.2 第二天：用 Envoy 实现零代码流量代理（省下 3 天开发）

你不需要重写 HTTP Server。Envoy 是现成的、经过大规模验证的流量代理，天生支持 Lua 插件，完美适配控制面需求。以下是我在线上环境跑了一年的配置精简版：

# envoy.yaml - 控制面流量入口 static_resources: listeners: - name: control_plane_listener address: socket_address: { address: 0.0.0.0, port_value: 8080 } filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: local_service domains: ["*"] routes: - match: { prefix: "/skill/" } route: { cluster: skill_backend } http_filters: - name: envoy.filters.http.lua typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua default_source_code: inline_string: | function envoy_on_request(request_handle) -- 1. 注入 TraceID local trace_id = request_handle:headers():get("x-request-id") or os.time() .. "-" .. math.random(10000,99999) request_handle:headers():add("x-trace-id", trace_id) -- 2. 鉴权前置检查（调用 Control Plane API） local auth_resp = request_handle:httpCall( "http://control-plane:8000/v1/authz", { [":method"] = "POST", [":path"] = "/v1/authz", ["content-type"] = "application/json" }, '{"agent_id":"web_ui","skill_id":"invoice_gen","user_id":"U123"}', 5000 ) if auth_resp[1] ~= 200 then request_handle:sendLocalResponse(403, "Forbidden by policy", {}, "application/json", 0) return end -- 3. 注入沙箱标识 request_handle:headers():add("x-sandbox-id", "prod-invoice-sandbox") end - name: envoy.filters.http.router

这个配置做了三件事：注入全局 TraceID、调用 Control Plane 的/v1/authz接口做实时鉴权、添加沙箱标识。所有 Agent Core 的 Skill 请求都走这个入口，无需修改一行业务代码。Envoy 的优势在于：它运行在用户空间，性能损耗 < 3%，且自带熔断、重试、超时控制——这些本该是控制面的基础能力，何必自己造轮子？

注意：Envoy 的 Lua 插件不支持阻塞式 HTTP 调用（如http_call是异步的），所以鉴权逻辑必须用httpCall并处理回调。别试图用os.execute调用 curl，那会严重拖慢吞吐量。

3.3 第三天：用 SQLite 实现策略引擎原型（够用半年）

别被“策略引擎”吓住。企业初期最需要的不是 Drools 那种复杂规则引擎，而是一个能快速增删改查、支持基本条件判断的轻量方案。SQLite 完美胜任，且单文件、零依赖、ACID 保证。

我设计的策略表结构如下（实际生产用 PostgreSQL，但 SQLite 用于验证逻辑）：

-- policies 表：存储所有策略 CREATE TABLE policies ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, -- 如 "finance_read_only" description TEXT, enabled BOOLEAN DEFAULT 1, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- policy_rules 表：每条策略的规则条件 CREATE TABLE policy_rules ( id INTEGER PRIMARY KEY, policy_id INTEGER REFERENCES policies(id), field TEXT NOT NULL, -- 如 "skill_id", "user_role", "time_of_day" operator TEXT NOT NULL CHECK(operator IN ('==', '!=', 'in', 'not_in', '>=', '<=')), value TEXT NOT NULL, -- 如 "invoice_gen", "['admin','auditor']", "09:00" order_num INTEGER DEFAULT 0 ); -- policy_bindings 表：策略绑定到哪些 Agent/Skill CREATE TABLE policy_bindings ( id INTEGER PRIMARY KEY, policy_id INTEGER REFERENCES policies(id), target_type TEXT NOT NULL CHECK(target_type IN ('agent', 'skill', 'user')), target_id TEXT NOT NULL, -- 如 "crm_sync_agent", "pdf_gen_skill", "U123" priority INTEGER DEFAULT 0 -- 数值越大优先级越高 );

鉴权 API/v1/authz的核心逻辑就 20 行 Python：

# control_plane/app.py from fastapi import FastAPI, HTTPException import sqlite3 import json from datetime import datetime app = FastAPI() conn = sqlite3.connect("policies.db") @app.post("/v1/authz") def check_authorization(request: dict): agent_id = request.get("agent_id") skill_id = request.get("skill_id") user_id = request.get("user_id") # 1. 查找所有绑定到该 agent/skill/user 的策略 cursor = conn.cursor() cursor.execute(""" SELECT p.id, p.name, pr.field, pr.operator, pr.value FROM policies p JOIN policy_rules pr ON p.id = pr.policy_id JOIN policy_bindings pb ON p.id = pb.policy_id WHERE pb.target_type = ? AND pb.target_id = ? ORDER BY pb.priority DESC """, ("skill", skill_id)) rules = cursor.fetchall() if not rules: return {"allowed": True, "reason": "no policy matched"} # 2. 逐条执行规则（简化版，实际需支持嵌套逻辑） for rule in rules: field, op, value = rule[2], rule[3], rule[4] actual_value = {"skill_id": skill_id, "user_id": user_id}.get(field, "") if op == "==" and actual_value != value: raise HTTPException(403, f"Policy {rule[1]} blocked: {field} {op} {value}") if op == "in" and actual_value not in json.loads(value): raise HTTPException(403, f"Policy {rule[1]} blocked: {field} not in {value}") return {"allowed": True}

这个原型跑通后，你会发现：策略管理从“改代码”变成“写 SQL”，运营同学也能自助配置。这才是控制面该有的样子——能力下沉，操作上浮。

3.4 第四天：用 Docker BuildKit 实现 Skill 沙箱（安全又高效）

“deepseek harness skill读取文件报权限问题” 这类问题，根源是 Skill 运行时拥有过高权限。解决方案不是给 Skill 加更多 if-check，而是从容器层剥夺权限。

Docker BuildKit 的--mount=type=bind支持只读挂载和子路径限制，配合--cap-drop=ALL，能构建出极简沙箱：

# skill/Dockerfile # 使用 distroless 基础镜像，无 shell，无包管理器 FROM gcr.io/distroless/python3-debian12 # 复制 Skill 代码（仅复制必要文件，不包含 .git 或测试目录） COPY --chown=nonroot:nonroot skill.py /app/skill.py COPY --chown=nonroot:nonroot requirements.txt /app/requirements.txt # 创建非 root 用户 RUN addgroup -g 1001 -f app && adduser -S app -u 1001 # 设置工作目录和用户 WORKDIR /app USER app # 安装依赖（BuildKit 在构建时完成，运行时不需 pip） RUN pip install --no-cache-dir -r requirements.txt # 关键：声明只读挂载点，运行时由 Control Plane 注入 VOLUME ["/data/input", "/data/output"] # 入口点严格限定 ENTRYPOINT ["python", "skill.py"]

Control Plane 启动 Skill 容器的命令：

# 启动时，Control Plane 动态指定挂载路径和权限 docker run \ --rm \ --cap-drop=ALL \ # 剥夺所有 Linux capabilities --read-only \ # 根文件系统只读 --tmpfs /tmp:size=10m \ # /tmp 为内存盘，防写满 -v $(pwd)/sandbox/invoice_data:/data/input:ro \ # 只读挂载输入数据 -v $(pwd)/sandbox/output:/data/output:rw \ # 可写挂载输出目录 -e SKILL_CONFIG='{"timeout":30,"max_tokens":2000}' \ invoice-skill:1.2

这个沙箱做到了：

• Skill 无法写入根目录、无法执行ls /etc、无法创建新进程（fork被禁用）；
• 输入数据只能从/data/input读，输出只能写到/data/output；
• 即使 Skill 代码里有os.system("rm -rf /")，也会因权限不足静默失败。

比任何代码层的权限检查都可靠。

3.5 第五天：用 OpenTelemetry Collector 实现全链路追踪（不改一行业务代码）

“agent execution terminated due to error” 这种模糊错误，90% 源于无法定位失败环节。OpenTelemetry Collector 是目前最成熟的开源方案，关键是它支持“无侵入式”注入。

步骤很简单：

1. 在 Envoy 配置中启用 tracing（前面已展示）；
2. 部署 OpenTelemetry Collector（官方 Helm Chart 一键安装）；
3. 在 Agent Core 的 Skill 代码中，只加 3 行初始化（以 Python 为例）：

# skill.py - 仅需这三行，无需修改任何业务逻辑 from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter provider = TracerProvider() processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4318/v1/traces")) provider.add_span_processor(processor) trace.set_tracer_provider(provider)

Collector 的配置collector.yaml：

receivers: otlp: protocols: http: exporters: jaeger: endpoint: "jaeger:14250" logging: loglevel: debug service: pipelines: traces: receivers: [otlp] exporters: [jaeger, logging]

效果立竿见影：在 Jaeger UI 中，输入一个 TraceID，你能看到完整的调用树：
Web UI → Envoy (鉴权) → Control Plane (策略检查) → Skill A (查数据库) → LLM API → Skill B (生成 PDF) → S3 Upload
每个节点显示耗时、状态码、错误堆栈。当某次执行失败，一眼就能看到是 LLM 返回了 429（限流），还是 Skill B 的 S3 凭据过期了。这才是真正的可观测性。

3.6 第六天：用 GitOps 实现声明式部署（告别手工 SSH）

“deepseek harness如何安装插件”、“deepseek harness插件推荐” 这些搜索，暴露了一个事实：大家还在用pip install手动装插件。这在生产环境是灾难。

GitOps 的核心思想：配置即代码，变更即提交。

创建一个agent-manifests仓库，目录结构如下：

├── agents/ │ ├── crm-sync/ │ │ ├── agent.yaml # Agent 元信息 │ │ └── skills/ │ │ ├── db-query.yaml # Skill A 定义 │ │ └── email-send.yaml # Skill B 定义 │ └── invoice-gen/ │ ├── agent.yaml │ └── skills/ │ └── pdf-gen.yaml └── policies/ └── finance-read-only.yaml

agents/crm-sync/agent.yaml示例：

apiVersion: agent.harness.io/v1 kind: Agent metadata: name: crm-sync-agent version: 1.3.0 spec: description: "Sync CRM data to internal DB" owner: "sales-team@company.com" skills: - name: db-query version: 2.1.0 permissions: network: ["internal-db.company.com:5432"] files: ["/data/input/", "/data/output/"] resources: cpu: "500m" memory: "512Mi" tokens: 5000 - name: email-send version: 1.0.0 permissions: network: ["smtp.company.com:587"]

Control Plane 的 Operator 监听这个仓库的 push 事件，自动解析 YAML，调用 Docker Registry 拉取对应 Skill 镜像，更新数据库中的 Agent 配置，并触发 Envoy 配置热重载。整个过程无人工干预，且每次变更都有 Git Commit 记录，满足审计要求。

3.7 第七天：集成企业已有系统（AD/LDAP、CMDB、监控平台）

控制面不是孤岛。第七天，把它焊接到企业 IT 基座上：

• 身份集成：Control Plane 的/v1/authz接口，不自己存用户密码，而是调用企业 AD/LDAP 的 REST API（如 Microsoft Graph API）做实时认证。这样，HR 新增员工，第二天就能用 Agent；员工离职，权限自动失效。
• 资产集成：从 CMDB 拉取数据库、API 网关、消息队列的元数据，自动填充到策略引擎的network和files字段。例如，CMDB 中标记mysql-prod的 IP 是10.1.2.3，那么策略中写network: ["mysql-prod"]就自动映射为10.1.2.3:3306。
• 告警集成：Control Plane 的健康检查端点/healthz，直接对接企业 Zabbix 或 Prometheus Alertmanager。当策略引擎响应延迟 > 200ms，或沙箱容器启动失败率 > 5%，立即触发企业微信/钉钉告警，并附带 TraceID 链接。

做完这七天，你手上就有了一个虽小但五脏俱全的控制面：它不替代你的 Agent 框架，而是成为它的“监管者”和“赋能者”。接下来，就是根据业务增长，逐步增强——比如第八天加入 LLM Token 成本分析，第九天接入 WAF 防御 prompt 注入，第十天支持多云调度……但地基，已经打牢。

4. 避坑指南：那些只有踩过才懂的控制面陷阱

4.1 陷阱一：把控制面做成“万能胶水”，结果粘不住任何东西

最典型的错误，是试图用控制面解决所有问题：既要管 Agent，又要管 LLM API Key，还要管向量数据库权限，最后连前端按钮的显隐都要它控制。结果呢？控制面越来越重，每次发布都要停服半小时，团队抱怨“改个按钮要走控制面发布流程，比改前端还慢”。

我的经验：控制面只做四件事——鉴权、隔离、追踪、部署。其他一切，交给专业系统。LLM Key 管理用 HashiCorp Vault；向量库权限用 ChromaDB 自带的 RBAC；前端按钮显隐，前端自己根据用户角色判断（角色信息从控制面/v1/user/{id}接口获取）。控制面是“守门人”，不是“包工头”。

4.2 陷阱二：策略引擎追求“图灵完备”，最后没人敢改

有团队引入 Drools，写了一堆 DRL 规则，结果运营同学想改一条“周末禁止调用支付 Skill”，得找 Java 工程师改代码、打包、发布……一周后才上线。策略失去了敏捷性。

实操心得：策略必须“低代码”。我坚持用 YAML/JSON 定义规则，配合一个简单的 Web UI（Vue + FastAPI），让运营同学能：

• 从下拉菜单选field（skill_id, user_role, time_of_day）；
• 选operator（==, in, >=）；
• 填value（字符串或数组）；
• 拖拽调整priority。
  UI 后端把配置转成前面提到的 SQLite 表记录。改一条策略，30 秒生效。复杂逻辑？拆成多条简单规则组合。

4.3 陷阱三：沙箱太“干净”，导致 Skill 无法运行

曾有个团队把沙箱做得极其严格：--read-only+--cap-drop=ALL+--tmpfs /tmp，结果所有 Skill 启动就报错——因为 Python 的pip install需要写/tmp，某些 SDK 初始化要读/proc/cpuinfo。

避坑技巧：沙箱不是越严越好，而是“恰到好处”。我的黄金法则是：

• 网络：默认 deny-all，只显式允许network: ["xxx"]；
• 文件：根目录只读，但/tmp设为 tmpfs（内存盘），/dev/shm允许读写（很多 Python 库依赖它）；
• Capabilities：只保留CAP_NET_BIND_SERVICE（如果 Skill 需要 bind port）、CAP_SYS_CHROOT（如果要用 chroot），其余全 drop；
• 进程：用--pids-limit=10限制最大进程数，防 fork bomb。
  每次新增 Skill，先在宽松沙箱跑通，再逐步收紧，直到找到最小权限集。

4.4 陷阱四：追踪只埋点，不建模，最后全是噪音

很多团队上了 OpenTelemetry，Jaeger 里满屏红色 span，但点开全是HTTP GET /healthz或redis.GET cache_key，真正的业务链路被淹没。

关键动作：必须定义“业务 Span”。在 Agent Core 的主入口，强制创建一个agent.executespan，所有子 Span 都是它的 child。代码示例：

# agent_core/main.py with tracer.start_as_current_span("agent.execute", attributes={ "agent.id": "invoice-gen", "session.id": "S123456", "user.id": "U789" }) as parent_span: # 所有 Skill 调用都在此 span 下 result_a = skill_a.run(...) result_b = skill_b.run(...)

同时，在 Envoy 的 Lua 插件中，把x-trace-id注入到所有下游请求头。这样，从用户点击到最终 PDF 生成，所有组件都在同一颗 Span 树下。没有业务语义的追踪，只是日志的另一种形式。

4.5 陷阱五：部署追求“全自动”，却忘了“可逆性”

GitOps 很好，但有个致命前提：回滚必须和部署一样快。我见过最惨的事故：一个团队用 Argo CD 自动部署，新版本 Skill 有严重内存泄漏，Argo 发现 CPU > 90% 后触发 rollback，但 rollback 操作本身要 8 分钟——这 8 分钟里，所有 Agent 都不可用。

血泪教训：回滚必须是“原子切换”，不是“重新部署旧版”。我的方案是：

• Control Plane 维护两个 Skill 版本镜像的引用（v1.2.0和v1.2.1）；
• Envoy 的路由配置中，cluster指向一个逻辑名invoice-skill-active；
• 回滚时，Control Plane 只需更新invoice-skill-active指向v1.2.0的镜像地址，然后发送 SIGHUP 通知 Envoy 重载配置；
• 整个过程 < 1 秒，且旧版容器保持运行，无缝切换。

永远记住：在生产环境，“能回滚”比“能部署”更重要。一个无法秒级回滚的自动化，是定时炸弹。

5. 控制面的未来：从“稳定”到“智能”的演进路径

控制面不会停留在“稳定”层面。随着 Agent 规模扩大，它会自然进化出更高级的能力。这不是幻想，而是我们已经在客户现场验证的路径：

5.1 阶段一：稳定性基建（0~6个月）

目标：让 Agent 不宕机、不越权、不出错、可追溯。
交付物：Envoy 代理 + SQLite 策略 + Docker 沙箱 + OpenTelemetry 追踪 + GitOps 部署。
这是生存线，必须先达标。

5.2 阶段二：成本与效能优化（6~12个月）

当 Agent 日均调用量破万，Token 成本、GPU 显存、网络带宽开始成为瓶颈。控制面要升级：

• LLM Token 智能路由：根据提示词长度、历史成功率、模型负载，自动选择deepseek-v2或qwen2-7b，而非硬编码；
• 缓存决策引擎：对“查天气”、“查汇率”等幂等 Skill，控制面自动插入 Redis 缓存层，命中率 > 80%；
• 资源弹性伸缩：监控 Skill 的 CPU/内存曲线，自动扩缩容其所在 K8s Pod，避免为峰值预留过多资源。

此时，控制面从“守门人”变成“管家”。

5.3 阶段三：自治与协同（12个月+）

终极形态：控制面具备“元认知”能力。

• 异常自愈：当检测到某 Skill 连续 5 次rpc error (-1): empty sid and service name，自动隔离该 Skill，触发告警，并尝试用备用 Skill（如降级为规则引擎）兜底；
• 技能协同编排：用户说“帮我分析这份财报”，控制面自动拆解为“PDF 解析 Skill → 表格提取 Skill → 财务指标计算 Skill → 生成 PPT Skill”，并管理它们之间的数据契约（Schema）；
• 安全左移：新 Skill 提交 PR 时，Control Plane 的 CI 流水线自动运行：静态扫描（检测硬编码密钥）、沙箱行为分析（观察是否尝试访问/etc/shadow）、提示词鲁棒性测试（用对抗样本检测 jailbreak）。

这听起来很远？其实，我们已在某证券公司的“研报生成 Agent”中实现了第一项：异常自愈。当 PDF 解析 Skill 因格式问题崩溃，控制面 2 秒内切换到备用 OCR Skill，用户无感知。技术上，它只是把前面七天的模块，用更复杂的状态机串联起来。

回到标题：“Harness 不只是管好模型”。这句话的深意，是提醒我们：当 AI Agent 从玩具变成生产力工具，真正的技术挑战，早已不在模型层，而在如何让智能体集群像水电一样稳定、可靠、可控。控制面，就是那个让 AI 从“能用”走向“敢用”的关键基础设施。它不性感，不炫技，但当你深夜收到告警，打开 Jaeger 看到清晰的失败路径，用一条 SQL 精准定位违规 Skill，或者在 3 秒内回滚掉引发雪崩的代码——那一刻，你会明白，为什么值得为它投入时间。

我个人在实际操作中的体会是：别等 Agent 上线后再补控制面。从第一个 Skill 开发的第一天起，就把 Envoy 代理、策略表、沙箱配置、追踪埋点，当成和requirements.txt一样的必需品。因为，修复一个失控的 Agent 集群，比从零搭建一个控制面，要难十倍。