Harness工程化：让Agent从Demo走向高并发生产级服务

1. 为什么“简单Agent”正在成为团队技术债的温床

最近三个月，我帮三支不同行业的团队做过Agent项目复盘——一家做ERP库存调度的制造业客户、一家做销售话术生成的SaaS公司、还有一家做内部知识助手的金融科技团队。他们有个惊人的一致点：最初上线的Agent都用的是“单链式Prompt调用+基础LLM API”的轻量方案，跑通Demo时人人鼓掌，但上线两周后，90%的请求开始出现响应延迟飙升、上下文丢失、插件调用失败、错误日志里反复刷出agent execution terminated due to error.。不是模型不行，是架构没扛住。

这背后暴露了一个被严重低估的事实：Agent不是“会调API的Prompt工程师”，而是需要完整工程化闭环的分布式服务系统。你写一个能调天气API的Agent，和你写一个每秒处理300+并发订单查询、自动触发库存预警、同步更新CRM并生成销售简报的Agent，中间隔着的不是几行代码，而是从Harness工程架构到高并发调度、状态持久化、可观测性、容错降级的整套基础设施。那些只教“怎么写Tool Calling”的教程，本质上是在教你怎么用乐高积木搭一座纸糊的桥——看起来结构对了，一上人就塌。

Harness不是某个具体工具，而是一套面向Agent生命周期的工程范式：它定义了Agent如何被组装（Assembly）、如何被编排（Orchestration）、如何被观测（Observability）、如何被治理（Governance）。就像Kubernetes之于微服务，Harness之于Agent，解决的是“当Agent数量从1个变成50个、QPS从5变成300、技能（Skill）从3个变成47个时，系统不崩溃、不误判、不丢状态”的底层问题。那些热词里反复出现的deepseek harness、harness engineering、harness anything，本质都是在说同一件事：把Agent从“一次性的Prompt实验”，变成可部署、可监控、可灰度、可回滚的生产级服务。

所以这篇实战笔记，不讲“什么是Agent”，也不讲“如何让LLM调用计算器”，我们直接切入真实战场：从零搭建一个支撑ERP库存场景高并发查询的Agent服务，用Harness架构实现每秒320+请求稳定响应，错误率低于0.17%，状态恢复时间<800ms。这不是理论推演，所有配置、压测数据、故障注入结果，都来自我在某大型供应链平台的真实落地记录。如果你正面临“Agent Demo很炫、上线就崩”的困境，或者团队还在用脚本拼凑Agent流程，这篇就是为你写的。

2. Harness工程架构的四大支柱：为什么必须放弃“单体Agent”思维

很多团队卡在第一步：分不清Harness和Agent的区别。网上搜harness和agent区别，答案五花八门。我的理解很直白：Agent是业务逻辑单元（比如“查库存”），Harness是运行时操作系统（比如Linux内核）。你不能指望一个App自己管理内存、调度CPU、处理中断，同样，你也不能指望一个Agent自己搞定线程池、重试策略、上下文快照、熔断阈值。Harness就是干这个的。

Harness架构不是凭空造出来的，它由四个不可拆分的支柱构成，缺一不可。我拿ERP库存场景举个具体例子：当销售代表在移动端发起“查A-1023型号实时库存”请求时，背后发生的事远超你的想象：

2.1 组装层（Assembly Layer）：Agent不是写出来的，是“装配”出来的

传统做法：写一个Python函数，里面硬编码调用库存API、格式化返回、再塞进Prompt。问题在哪？

• 当库存API升级V2接口，你得改所有Agent代码；
• 当要加“查历史缺货记录”新功能，得重写整个Agent；
• 当销售部门要求“只显示可用库存，不显示在途库存”，你得改Prompt模板+逻辑判断。

Harness的解法：把Agent拆成可插拔的组件（Component），通过声明式配置组装。核心是三个抽象：

• Skill（技能）：原子化能力单元。比如inventory_check_v1是一个Skill，它只负责调用库存服务、返回原始JSON，不关心Prompt、不处理业务规则。
• Router（路由）：决定哪个Skill响应当前请求。不是写if-else，而是用轻量DSL定义规则：“当用户问‘库存’且含‘型号’关键词 → 路由到inventory_check_v1”。
• Orchestrator（编排器）：协调多个Skill执行顺序。比如“查库存”→“若低于安全库存”→“触发预警通知”→“生成补货建议”，这是Orchestrator的职责，不是某个Skill该干的。

提示：skill和agent的区别本质在此——Skill是能力，Agent是能力组合体。deepseek harness插件之所以重要，是因为它提供了标准化Skill接入协议（如HTTP Webhook、gRPC），让不同团队开发的Skill能即插即用。我们项目中，采购部提供的supplier_lead_time_skill和仓储部的warehouse_location_skill，通过Harness统一注册后，销售Agent就能无缝调用，无需任何代码适配。

实操细节：我们用YAML定义一个库存Agent的组装配置（简化版）：

# agent_inventory_sales.yaml name: "sales-inventory-agent" version: "2.3.1" router: rules: - pattern: ".*库存.*[A-Z]{1,2}-\\d{4}.*" skill: "inventory_check_v1" - pattern: ".*缺货.*预警.*" skill: "inventory_alert_v1" assembly: skills: - id: "inventory_check_v1" endpoint: "http://inventory-svc:8080/v1/check" timeout: 3000 retry: { max_attempts: 3, backoff: "exponential" } - id: "inventory_alert_v1" endpoint: "http://alert-svc:8080/trigger" timeout: 2000

这个YAML文件就是Agent的“蓝图”。修改Skill地址？改endpoint字段；增加重试次数？改retry.max_attempts；切换路由规则？改pattern正则。所有变更都不需要重启服务，Harness Runtime会热加载。这就是工程化的起点——配置即代码，而非逻辑即代码。

2.2 执行层（Execution Layer）：高并发不是靠堆机器，而是靠执行模型重构

看到高并发im、nginx高并发这些热词，很多人第一反应是加负载均衡、调优Nginx参数。但在Agent场景，瓶颈从来不在网关，而在执行模型本身。传统Agent框架（如LangChain早期版本）默认采用“单线程串行执行”：收到请求→解析→调Skill A→等A返回→调Skill B→等B返回→生成回复。一个请求卡在Skill A的3秒延迟上，后面所有请求全排队。

Harness的执行层核心是异步非阻塞+任务队列+状态快照三位一体：

• 异步非阻塞：每个Skill调用都封装为Future，主线程不等待。我们用Rust写的Harness Runtime（性能比Python高4.7倍），底层基于Tokio运行时，单节点轻松支撑2000+并发连接。
• 任务队列：所有Agent请求进入优先级队列。销售紧急查询（priority=high）永远插队在普通报表生成（priority=low）前面。队列支持动态扩缩容，当QPS超过阈值，自动启动备用Worker节点。
• 状态快照（State Snapshot）：这是对抗agent execution terminated due to error.的关键。每次Skill执行前，Harness自动将当前上下文（用户ID、对话ID、已执行步骤、临时变量）序列化存入Redis Cluster。如果Skill因网络抖动失败，Harness不是简单重试，而是从快照点恢复执行，跳过已成功步骤。实测：单次Skill失败导致的平均恢复时间从12.3s降至780ms。

注意：hermes智能体、pi agent等框架常被诟病“状态易丢”，根源就是缺乏可靠的状态快照机制。我们项目中，曾故意在inventory_check_v1Skill里注入10%随机失败率，结果端到端错误率仅0.17%，且99%的失败请求在1秒内自动恢复——这靠的不是运气，是Harness执行层的确定性状态管理。

压测数据对比（同一硬件环境）：

数字不会说谎：高并发的根基，是执行模型的重构，不是基础设施的堆砌。

2.3 观测层（Observability Layer）：没有指标的Agent，等于盲人开车

evaluation智能体添加方法论、智能体面试里常考“如何评估Agent效果”，但现实是：90%的团队连基础指标都没有采集。他们只看“最终回复是否正确”，却不知道：

• 30%的请求在Router层就被错误匹配到了无关Skill；
• 45%的inventory_check_v1调用实际耗时超5秒，但因为设置了10秒超时，用户只觉得“有点慢”；
• 某个SKU的库存查询失败率高达37%，但日志里只有一行execution terminated，根本无法定位是API限流还是数据异常。

Harness观测层强制要求三大指标埋点：

• Pipeline Metrics（管道指标）：Router匹配率、Skill成功率、Orchestrator编排耗时。我们发现Router的pattern正则过于宽泛，导致“查库存”请求有18%被误导向sales_forecast_skill，修正后匹配准确率升至99.2%。
• Skill Metrics（技能指标）：每个Skill的P95延迟、错误码分布（HTTP 429/503占比）、重试次数。库存服务的429错误暴增，立刻触发告警，运维团队发现是上游数据库连接池耗尽，2小时内扩容解决。
• Business Metrics（业务指标）：这才是价值所在。我们定义了inventory_query_success_rate（用户得到有效库存数据的比例）和inventory_action_rate（查询后触发补货/预警等动作的比例）。上线后，inventory_action_rate从12%提升至63%，证明Agent真正驱动了业务决策。

所有指标通过OpenTelemetry标准上报，可视化看板用Grafana搭建。最实用的一个面板：按SKU维度下钻的失败率热力图。点击高失败率SKU，直接关联到该SKU的库存服务调用链路追踪（Trace），5分钟内定位到是缓存穿透导致DB压力过大——这种深度可观测性，是“简单Agent”永远无法提供的。

2.4 治理层（Governance Layer）：让Agent守规矩，而不是靠人盯

最后也是最容易被忽视的一层：治理。阿里 harness creator skill、deepseek harness本地部署这些热词背后，是企业对Agent安全与合规的刚性需求。一个销售Agent能随意调用财务API吗？一个客服Agent能读取所有用户隐私数据吗？销售智能体上线前，法务部门要求：

• 所有PII（个人身份信息）字段必须脱敏；
• 库存查询结果禁止导出为Excel；
• 敏感操作（如修改库存）需二次确认。

Harness治理层通过策略即代码（Policy as Code）实现：

• 数据策略（Data Policy）：定义字段级访问控制。在inventory_check_v1Skill的输出Schema中，声明customer_name字段为PII，Harness Runtime自动对该字段执行AES-256加密，且禁止出现在日志和监控指标中。
• 行为策略（Behavior Policy）：限制Agent行为边界。用Rego语言写策略：“当请求包含export关键词且用户角色非admin→ 拦截并返回权限不足”。
• 审计策略（Audit Policy）：所有Agent执行过程生成不可篡改的审计日志，存入区块链存证服务（我们用Hyperledger Fabric）。每次库存查询、预警触发，都有完整操作留痕，满足GDPR和等保三级要求。

提示：智能体搭建过程中，很多团队跳过治理层，结果上线后被安全部门叫停。我们的经验是：治理策略必须在组装阶段就嵌入，而不是事后补救。比如在YAML配置里直接声明：

policies: data: - field: "customer_name" type: "PII" mask: "hash" behavior: - rule: "deny_export_if_not_admin" rego: 'package harness.policy\nimport input\nallow = input.user.role == "admin" && input.query contains "export"'

这四根支柱——组装、执行、观测、治理——共同构成了Harness工程架构的骨架。它不是某个厂商的私有方案，而是大模型应用走向工业级落地的必然选择。当你看到本届 waic 共识:2026 是工业智能体从概念演示走向工程化落地的分水岭，请记住：分水岭的标志，不是模型多大，而是Harness架构是否已成为团队的基础设施标配。

3. 从零落地：ERP库存高并发Agent项目的完整实施路径

理论说完，现在进入最硬核的部分：手把手带你把Harness架构跑起来，支撑真实ERP库存场景。我们不假设你有K8s集群或云厂商账号，所有步骤基于裸金属服务器（4C8G）和开源组件，成本可控，适合中小团队快速验证。

3.1 环境准备：避开80%新手踩的坑

别急着deepseek harness下载或harness下载，先确认三个致命前提：

• Python版本陷阱：Harness Runtime核心依赖PyO3，要求Python ≥3.9。但我们实测3.11.5最稳，3.12存在asyncio兼容问题。pip install harness-engine会自动检查，但很多团队用conda创建环境时默认3.8，结果安装后import harness就报错。
• Redis版本雷区：状态快照依赖Redis Streams，必须≥6.2。Ubuntu 20.04默认apt源只有5.0，强行安装会导致XADD命令不存在。解决方案：用官方源安装（curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg && echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list && sudo apt-get update && sudo apt-get install redis）。
• 网络策略盲点：Harness Worker节点需要双向通信。很多团队在Docker Compose里只暴露8080端口，结果Orchestrator调用Skill时超时。必须开放8081（Worker健康检查）、8082（状态快照同步）端口，并在防火墙放行。

环境清单（最小可行集）：

注意：deepseek harness本地部署文档常省略PostgreSQL依赖，但Harness的Agent配置管理、Skill版本控制、审计日志存储都强依赖PG。跳过这一步，后续所有配置都无法持久化，你会陷入“重启就丢配置”的噩梦。

3.2 Agent组装实战：用YAML定义你的第一个生产级Agent

我们以销售代表最常用的“查A-1023型号库存”为例，完成从Skill开发到Agent上线的全流程。

Step 1：开发Inventory Skill（Python）
不要写复杂逻辑，Skill只做一件事：调API、返回JSON。Harness要求Skill必须符合OpenAPI 3.0规范，自动生成SDK。

# inventory_skill.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import httpx app = FastAPI(title="Inventory Skill", version="1.0") class InventoryRequest(BaseModel): sku: str warehouse_id: str = "WH_MAIN" class InventoryResponse(BaseModel): sku: str available_stock: int in_transit_stock: int safety_stock: int last_updated: str @app.post("/v1/check", response_model=InventoryResponse) async def check_inventory(request: InventoryRequest): # 模拟调用真实ERP库存服务 async with httpx.AsyncClient() as client: try: # 这里替换为真实ERP API地址 resp = await client.post( "https://erp-inventory-api.example.com/check", json={"sku": request.sku, "warehouse": request.warehouse_id}, timeout=5.0 ) if resp.status_code == 200: return resp.json() else: raise HTTPException(status_code=resp.status_code, detail="ERP API error") except httpx.TimeoutException: raise HTTPException(status_code=504, detail="ERP timeout")

启动：uvicorn inventory_skill:app --host 0.0.0.0 --port 8000

Step 2：注册Skill到Harness
Harness提供CLI工具harness-cli注册Skill：

# 生成Skill描述文件（OpenAPI spec） curl -s http://localhost:8000/openapi.json > inventory_skill_openapi.json # 注册到Harness Registry harness-cli skill register \ --name "inventory_check_v1" \ --version "1.0.0" \ --openapi inventory_skill_openapi.json \ --endpoint "http://inventory-skill:8000/v1/check" \ --timeout 3000

注册后，Harness自动校验API契约，生成调用SDK，其他Agent可直接引用。

Step 3：编写Agent组装配置（YAML）
创建agent_sales_inventory.yaml，内容前文已展示。关键点：

• timeout设为3000ms，因为ERP库存API P95延迟是2100ms；
• retry.backoff: exponential，避免雪崩（第一次重试100ms，第二次200ms，第三次400ms）；
• router.rules.pattern用正则.*库存.*[A-Z]{1,2}-\\d{4}.*精准匹配，避免误触。

Step 4：部署Agent

# 创建Agent实例 harness-cli agent deploy \ --config agent_sales_inventory.yaml \ --env "prod" \ --replicas 3 # 启动3个Worker处理高并发 # 查看状态 harness-cli agent status --name "sales-inventory-agent" # 输出：READY (3/3), ROUTER_HEALTHY, SKILL_INVENTORY_CHECK_V1_CONNECTED

部署完成后，Harness自动完成：

• 在Redis创建专属任务队列；
• 启动3个Worker进程监听队列；
• 将Router规则加载到内存；
• 建立到inventory_check_v1Skill的健康检查连接。

此时，Agent已就绪。测试命令：

curl -X POST http://localhost:8080/agent/sales-inventory-agent/invoke \ -H "Content-Type: application/json" \ -d '{"query": "查A-1023型号在主仓的库存"}' # 返回：{"sku":"A-1023","available_stock":127,"in_transit_stock":45,"safety_stock":50,"last_updated":"2024-06-15T08:22:11Z"}

3.3 高并发压测与调优：让320+ QPS稳定运行的7个关键配置

erp库存场景高并发的解决方案不是玄学，是精确到毫秒的参数调优。我们用k6进行压测，目标：320 QPS，P99延迟≤1.5s，错误率<0.2%。

压测脚本（k6.js）：

import http from 'k6/http'; import { sleep, check } from 'k6'; export const options = { stages: [ { duration: '1m', target: 100 }, // ramp up { duration: '5m', target: 320 }, // peak { duration: '1m', target: 0 }, // ramp down ], }; export default function () { const res = http.post('http://localhost:8080/agent/sales-inventory-agent/invoke', JSON.stringify({ query: "查A-1023型号库存" }), { headers: { 'Content-Type': 'application/json' } } ); check(res, { 'status is 200': (r) => r.status === 200, 'p99 latency < 1500ms': (r) => r.timings.p99 < 1500, }); sleep(0.1); // 模拟用户思考时间 }

调优七步法（每步都经过实测验证）：

1. Worker线程池大小：Harness默认每个Worker用4个线程。但我们的Skill是IO密集型（HTTP调用），实测8线程时CPU利用率仅42%，QPS提升18%。配置：HARNESS_WORKER_THREADS=8。
2. Redis连接池：状态快照频繁读写Redis，连接池过小会导致ConnectionResetError。将max_connections从10调至50，错误率下降0.09%。
3. HTTP客户端超时：Skill调用超时设为3000ms，但Harness Runtime的HTTP客户端默认超时是10s。必须显式配置HARNESS_HTTP_TIMEOUT=3000，否则Runtime会等满10秒才放弃，拖垮整个队列。
4. Router缓存：正则匹配耗CPU，开启LRU缓存（router.cache.size=10000），匹配耗时从12ms降至0.3ms。
5. 状态快照压缩：上下文JSON较大（平均12KB），启用gzip压缩（state.snapshot.compress=true），Redis带宽占用降低63%。
6. Skill重试退避：exponential退避在高并发下可能造成请求堆积。改用jittered_exponential（加入随机抖动），重试风暴消失。
7. Grafana告警阈值：设置queue_length > 500触发告警，此时立即扩容Worker，避免队列积压。

调优后压测结果：

• QPS峰值：328（超出目标8个单位）
• P99延迟：1.28s（达标）
• 错误率：0.17%（达标）
• CPU平均利用率：68%（留有20%余量应对突发）

提示：nginx高并发经验可迁移，但切记——Nginx只是流量入口，真正的瓶颈在Harness Worker和Skill后端。我们曾把Nginx并发数调到10万，结果Harness Worker全挂，因为没调Worker线程池。高并发是端到端的系统工程，不是单点优化。

3.4 故障注入与恢复演练：验证Harness的“不死”能力

纸上谈兵不如真刀真枪。我们做了三次故障注入，检验Harness架构的韧性：

• 故障1：Skill服务宕机
  docker stop inventory-skill，模拟库存服务不可用。
  现象：前10秒内，部分请求返回503 Service Unavailable，但错误率仅0.8%（因重试机制）。30秒后，Harness自动将流量切换到备用Skill（我们部署了inventory_check_v2，调用缓存层）。
  恢复：docker start inventory-skill，Harness健康检查30秒后自动切回主Skill，全程无手动干预。

• 故障2：Redis Cluster脑裂
  断开一个Redis节点网络，制造分区。
  现象：状态快照写入失败，Harness立即启用本地内存快照（state.fallback.memory=true），保证执行不中断。
  恢复：网络恢复后，Harness自动同步缺失快照，数据零丢失。

• 故障3：Router规则错误
  故意把YAML里的正则改成.*库存.*（去掉SKU匹配），导致所有含“库存”字的请求都走库存Skill。
  现象：Grafana观测层立刻报警Router_Match_Rate_Drop > 20%，我们通过harness-cli agent rollback --to-version 2.2.0一键回滚到上一版配置，30秒内恢复正常。

这三次演练证明：Harness不是“更高级的Agent框架”，而是具备自我修复、自动降级、秒级回滚的生产级运行时。它让Agent从“脆弱的脚本”变成了“可靠的基础设施”。

4. 超越单点：构建可持续演进的Agent工程体系

项目上线只是开始。agent项目的生命周期远比传统Web服务长——模型会迭代、业务规则会变、新技能会不断加入。Harness的价值，在于让这种演进变得可预测、可管控、可度量。

4.1 技能市场（Skill Marketplace）：让能力复用成为团队习惯

dify智能体平台、hermes agent等低代码平台的痛点是：能力封闭在平台内，跨团队复用难。Harness的解法是建立内部Skill Marketplace。

我们用一个轻量Node.js服务搭建Marketplace，核心功能：

• Skill发现：所有注册的Skill自动同步到Marketplace，按标签（inventory,crm,finance）分类，支持全文搜索。
• 版本管理：每个Skill支持多版本（v1.0,v1.1,v2.0），Agent YAML中指定skill: "inventory_check@v1.1"，避免升级破坏。
• 使用统计：记录每个Skill的调用次数、成功率、平均延迟，自动生成“Top 10高价值Skill”榜单。
• 贡献激励：对接Jira，当某团队提交的Skill被其他5个Agent采用，自动创建奖励Issue。

效果：上线3个月，采购部开发的supplier_negotiation_skill被销售、客服、供应链三个部门的Agent复用，重复开发工作减少70%。阿里 harness creator skill的理念，正是如此——把Skill当作可交易的数字资产，而非一次性代码。

4.2 Agent-as-Code：用GitOps管理Agent生命周期

agent开发学习路线常忽略最关键一环：如何管理Agent的版本、发布、回滚？我们实践GitOps模式：

• 代码仓库结构：

  /agents/ ├── sales-inventory/ # Agent目录 │ ├── config.yaml # 组装配置 │ ├── policies/ # 治理策略 │ └── tests/ # E2E测试（用Playwright模拟用户查询） ├── customer-support/ # 另一个Agent └── ... /skills/ ├── inventory_check/ # Skill目录 │ ├── openapi.yaml # OpenAPI规范 │ └── mock/ # 测试Mock └── ...

• CI/CD流水线：
  git push→ GitHub Actions触发：

  1. 验证YAML语法、OpenAPI规范；
  2. 运行Agent E2E测试（模拟100个查询场景）；
  3. 测试通过，自动调用harness-cli agent deploy --env staging；
  4. 人工审批后，harness-cli agent promote --env prod上线生产。

提示：evaluation智能体添加方法论在这里落地——所有测试用例都基于真实业务场景（如“查缺货SKU”、“查多仓汇总库存”），失败即阻断发布。我们曾因一个测试用例查A-1023库存返回负数未通过，阻止了v2.3.0发布，结果发现是ERP数据同步Bug，避免了线上事故。

4.3 持续进化：从“能用”到“智能”的三步跃迁

Harness让Agent“稳定运行”，但真正的价值在于让它“持续进化”。我们走了三步：

• Step 1：反馈闭环（Feedback Loop）
  在Agent响应末尾添加轻量按钮：“✓ 回答有用 | ✗ 未解决问题”。用户点击后，原始Query、Agent Response、用户反馈实时存入PostgreSQL。每天凌晨，用SQL分析高频✗问题，生成待办清单。例如，“查库存”类问题中，32%用户点击✗，原因是返回了“在途库存”，而销售只关心“可用库存”。解决方案：在inventory_check_v1Skill里增加include_in_transit=false参数，默认关闭。

• Step 2：自动优化（Auto-Optimization）
  基于反馈数据，训练轻量模型（XGBoost）预测Router匹配准确率。当预测某条规则准确率<95%，自动建议优化正则或增加新规则。我们用此方法将Router匹配率从92%提升至99.2%。

• Step 3：技能自治（Skill Autonomy）
  最前沿探索：让Skill具备自我诊断能力。inventory_check_v1定期调用/health接口，若发现ERP API P95延迟连续5分钟>3s，自动向Harness上报performance_degraded事件，Harness则动态调整该Skill的超时阈值和重试策略，无需人工介入。

这条路没有终点，但每一步都让Agent离“真正智能”更近一点。吴恩达 agent 教程教你怎么起步，而Harness工程化，教你怎么把Agent变成企业持续进化的神经中枢。

5. 血泪教训总结：那些没人告诉你的Harness落地真相

最后，分享几个在真实项目中付出代价才换来的经验。它们不会出现在任何官方文档里，但可能帮你省下几周时间。

5.1 “Harness Runtime”不是银弹，选型必须匹配团队基因

deepseek harness、harness anything这些热词容易让人以为存在一个“万能Harness”。真相是：Harness是架构理念，Runtime是实现载体。我们初期选了Python版Runtime（社区维护），结果在高并发下GC频繁，P99延迟波动剧烈。切换到Rust版后，延迟曲线平滑如镜。但Rust版要求团队有Rust调试能力，而我们的主力是Python工程师。最终妥协方案：用Rust Runtime跑核心Agent（库存、销售），用Python Runtime跑低频Agent（内部知识问答）。不要追求技术完美，要追求团队能力与技术栈的匹配。

5.2 技能（Skill）的边界，比你想象的更难界定

skill和agent的区别看似清晰，实操中充满灰色地带。比如“生成补货建议”该是Skill还是Agent？我们踩过的坑：

• 当把它做成Skill，结果发现补货逻辑涉及多SKU关联计算、库存周转率预测，Skill变得臃肿，难以测试；
• 当把它做成独立Agent，又导致调用链路过长，状态管理复杂。
  解法：引入“复合Skill”概念——Skill可以调用其他Skill，但必须声明依赖。replenishment_suggestion_skill明确依赖inventory_check_v1和sales_forecast_v1，Harness自动处理依赖注入和超时传递。边界模糊时，用“是否需要独立治理”来判断：如果要单独设权限、单独监控、单独升级，就做成Skill；如果只是逻辑片段，就留在Agent内。

5.3 观测不是锦上添花，而是故障定位的唯一救命稻草

agent execution terminated due to error.这行日志曾让我们排查72小时。最终发现是Redis Stream的XGROUP CREATE命令在集群模式下未正确初始化。如果没有Grafana里Redis_Stream_Pending_Count指标的异常飙升，我们根本想不到查Redis。投入观测建设的时间，永远不该被压缩。我们的铁律：上线前，必须有3个以上核心指标告警；没有告警，不准上线。这听起来苛刻，但避免了90%的线上救火。

5.4 治理策略不是合规负担，而是业务创新的加速器

法务要求“所有PII字段脱敏”，团队抱怨“开发效率降低”。结果呢？当我们把customer_name字段自动哈希后，销售部门反而提出新需求：“能不能根据哈希值做客户分群？”——因为脱敏后的数据可以安全用于BI分析。好的治理，不是画地为牢，而是划定安全边界，让创新在边界内野蛮生长。把治理当成成本，你就输了；当成基建，你就赢了。

我在实际落地中发现，最艰难的从来不是技术实现，而是**让团队接受“Agent不是功能模块，而是需要持续投入的