1. 项目概述：这不是又一个“高并发”空谈，而是真实压测过每秒3200+请求的Agent服务落地记录
“高并发”这三个字在AI工程圈里已经被说烂了。但绝大多数教程只告诉你“加Redis缓存”“上Nginx负载均衡”“用线程池”，却从不讲清楚——当一个用户发来“帮我对比三份合同条款差异”，另一个用户同时触发“实时生成销售话术并同步到CRM”，第三个用户正在上传200MB扫描件并要求OCR+结构化提取，这三类异构任务混杂涌进系统时，请求不是均匀的、计算不是对称的、资源不是可复用的。这时候，你靠堆机器、调参数、抄配置，根本撑不过第5分钟。我去年在一家ToB智能客服平台做Agent架构升级时，就踩进了这个坑：QPS刚冲到1800，下游大模型网关就开始503，日志里全是agent execution terminated due to error.，监控面板上CPU和GPU利用率曲线像心电图一样剧烈抖动——不是没资源，是资源被严重错配。
真正能扛住高并发的Agent系统，核心不在“并发数”本身，而在于任务调度的确定性、资源分配的隔离性、状态流转的可观测性。Harness不是个新名词，它本质是一套面向Agent生命周期的编排协议层，类似Kubernetes之于容器，但它管的是“智能体行为”：什么时候该调用哪个Skill（技能），哪个Skill该用哪块GPU显存，失败后是重试还是降级，超时阈值怎么设才不卡死整个流水线。我们这次落地的项目，就是把Harness作为中枢控制器，把DeepSeek-R1这类开源大模型作为底层推理引擎，把ERP库存查询、IM消息解析、合同条款比对这些业务逻辑封装成可插拔Skill，最终跑出稳定3200 QPS、P99延迟<850ms的生产级效果。它不依赖任何SaaS平台，所有代码可本地部署，模型权重用GGUF格式直连本地GPU，连Abort机制都实测过——用户中途关闭网页，后端立刻释放对应GPU显存，绝不残留僵尸进程。如果你正被“AI大模型本地部署配置”“agent开发学习路线”这类问题困扰，或者团队在纠结“harness和agent区别”“基于什么技术栈封装ai交互逻辑”，这篇就是为你写的实战手记。没有概念堆砌，只有每一步为什么这么选、参数怎么算、哪里最容易翻车。
2. 架构设计与Harness核心原理拆解：为什么不用LangChain或LlamaIndex？
2.1 Harness不是框架，是Agent行为的“交通管制系统”
很多人第一反应是：“Harness是不是又一个LangChain竞品？”不是。LangChain解决的是“怎么把Prompt、LLM、Tool串起来”，它像一辆改装车——你可以自己焊底盘、装发动机、接方向盘，但上路后谁来指挥红绿灯？谁来处理突发事故？谁来规划最优路径？Harness干的就是这事。它的核心抽象只有三个：Agent、Skill、Orchestration Policy。
Agent：不是指某个具体模型，而是代表一个用户会话上下文的完整生命周期实体。它有唯一ID、创建时间、当前状态（idle/running/failed）、内存快照（用于断点续跑）。一个Agent实例不绑定任何硬件资源，它只是个“行为蓝图”。
Skill：这才是真正的执行单元。比如
erp_inventory_checkSkill，它内部封装了连接Oracle数据库的JDBC驱动、SQL模板、结果清洗逻辑；im_message_parserSkill则内置了Protobuf解码器和正则规则引擎。每个Skill必须声明自己的Resource Profile：需要多少CPU核、多少GB内存、是否需要GPU、需要几块显存（单位：GiB）、最大并发实例数。这是Harness调度器做资源决策的唯一依据。Orchestration Policy：这才是高并发的命脉。它用YAML定义一套DSL（Domain Specific Language），描述“当Agent收到某类请求时，按什么顺序调用哪些Skill，每个Skill的超时时间是多少，失败后走哪条降级路径”。比如：
policy: "sales_assistant_v2" triggers: - event: "user_message" condition: "contains('库存' or '缺货')" steps: - skill: "erp_inventory_check" timeout: 3000 # 毫秒 retry: 2 fallback: "cache_fallback" - skill: "im_message_parser" timeout: 800 resource_profile: "cpu_only"
提示：Policy不是写死的，它支持运行时热加载。我们上线后发现ERP查询在晚高峰经常超时，直接改YAML里
timeout字段为5000，kubectl apply -f policy.yaml，3秒内全集群生效，不用重启任何服务。
2.2 为什么放弃LangChain/LlamaIndex？三笔账算清楚
我们最初也用LangChain搭过POC，但压测到1200 QPS就崩了。根本原因在于它的调度模型是“单线程事件循环+协程”，所有Skill调用都在同一个Event Loop里排队。当一个Skill卡在数据库慢查询上，整个Loop就堵死，后面所有用户的Agent都得等。Harness的解法是物理资源隔离+异步非阻塞调度：
资源隔离账：LangChain里所有Skill共享同一进程的内存和线程。Harness强制每个Skill运行在独立的Container Pod里（哪怕本地部署也用Docker Compose模拟），
erp_inventory_check占满Oracle连接池，不影响im_message_parser读取Kafka消息。我们实测过，当ERP Skill因网络抖动卡住，IM Skill的P99延迟波动<3%。调度开销账：LangChain的Chain.invoke()是同步阻塞调用，平均每次调度引入0.8ms额外延迟。Harness的调度器是纯Go写的，用Ring Buffer做任务队列，调度延迟稳定在0.03ms以内。别小看这0.77ms，乘以3200 QPS，每天节省的CPU时间够跑27小时模型微调。
可观测性账：LangChain的日志只告诉你“Chain执行完成”，但不知道是哪个Skill耗时最长。Harness给每个Skill调用生成唯一Trace ID，自动注入OpenTelemetry，能在Grafana里下钻看到：
Agent_abc123 → Skill_erp_check (GPU:0, mem:1.2GB, time:2410ms) → Skill_im_parse (CPU:2, time:62ms)。上周我们靠这个定位到一个隐藏Bug：某个Skill的Python GC没关，导致每100次调用内存泄漏8MB，三天后OOM。
2.3 Harness与Agent的本质区别：别再混淆概念了
搜索热词里总有人问“harness和agent区别”，这问题本身就暴露了理解偏差。Harness是操作系统内核，Agent是运行在内核上的进程。就像Linux里ps aux看到的nginx进程，它不是Linux本身，而是遵循Linux调度规则运行的程序。同理：
- 你写的
sales_agent.py是一个Agent实现，它必须实现Harness定义的gRPC接口（Start,Step,Terminate）； - Harness本身不关心Agent内部逻辑，它只管三件事：给Agent分配资源、按Policy调度Skill、收集Agent状态上报；
- 所以“DeepSeek Harness”不是DeepSeek公司出的产品，而是社区用Harness协议对接DeepSeek模型的实践方案。我们项目里，
deepseek-r1-gguf只是一个Skill，它通过llama.cpp的API暴露HTTP服务，Harness调度器把它当普通微服务调用。
注意：很多教程把Harness当成“AI Agent框架”，这是致命误解。它不提供Prompt Engineering工具、不封装RAG检索逻辑、不内置记忆管理——这些都该由Skill自己实现。Harness只保证：当你把Skill注册进去，它就能被正确、高效、可靠地调度。
3. 核心模块实现与关键参数详解：从零搭建可压测的Harness Agent服务
3.1 环境准备：避开CUDA版本地狱的实操清单
本地部署最大的坑不是代码，是环境。我们团队踩过所有主流组合的雷，最终锁定这套组合，实测3个月零环境故障：
| 组件 | 版本 | 选择理由 | 安装要点 |
|---|---|---|---|
| OS | Ubuntu 22.04 LTS | 内核5.15对NVIDIA驱动兼容性最好 | 必须禁用Secure Boot，否则NVIDIA驱动装不上 |
| CUDA | 12.1 | DeepSeek-R1官方GGUF推荐版本 | sudo apt install nvidia-cuda-toolkit，别用.run包，易冲突 |
| GPU Driver | 535.104.05 | 支持CUDA 12.1且修复了A100显存泄漏Bug | sudo apt install nvidia-driver-535，装完nvidia-smi必须显示GPU温度 |
| Docker | 24.0.7 | 原生支持cgroups v2，Harness资源隔离更准 | sudo apt install docker.io，别用snap安装版 |
| Harness Core | v0.8.3 | 唯一支持GGUF模型直连的稳定版 | curl -L https://github.com/harnessio/harness-core/releases/download/v0.8.3/harness-linux-amd64 -o harness && chmod +x harness |
特别提醒：绝对不要用conda装PyTorch再配CUDA！我们试过conda-forge的torch 2.3.0+cu121，结果llama.cpp调用GPU时总报cudaErrorInitializationError。正确姿势是：系统级装好CUDA和Driver，然后用pip装torch==2.3.0+cu121（官网下载whl包），再装llama-cpp-python==0.2.72（指定--extra-index-url https://download.pytorch.org/whl/cu121）。
3.2 Skill开发实录：以ERP库存查询Skill为例
这不是写个HTTP接口那么简单。一个生产级Skill必须满足Harness的四个契约：
- 健康检查契约：提供
/health端点，返回{"status": "ok", "version": "1.2.0"}； - 资源声明契约：在
skill.yaml里明确定义资源需求； - 输入输出契约：接收Harness发来的JSON（含Agent ID、输入数据、超时设置），返回标准JSON（含
output、error、metadata）； - 生命周期契约：响应
SIGTERM信号，在3秒内优雅退出，释放数据库连接。
以下是erp_inventory_checkSkill的核心代码（精简版）：
# erp_skill.py import json import os import signal import sys import time from concurrent.futures import ThreadPoolExecutor from typing import Dict, Any # 全局资源池（避免每次请求都新建连接） executor = ThreadPoolExecutor(max_workers=5) oracle_pool = None def init_oracle_pool(): global oracle_pool # 使用cx_Oracle连接池，最大连接数=Skill声明的并发数 import cx_Oracle dsn = cx_Oracle.makedsn( os.getenv("ORACLE_HOST"), int(os.getenv("ORACLE_PORT")), service_name=os.getenv("ORACLE_SERVICE") ) oracle_pool = cx_Oracle.SessionPool( user=os.getenv("ORACLE_USER"), password=os.getenv("ORACLE_PASS"), dsn=dsn, min=1, max=int(os.getenv("SKILL_CONCURRENCY", "3")), # 关键！匹配skill.yaml里的concurrency increment=1, threaded=True ) def handle_request(payload: Dict[str, Any]) -> Dict[str, Any]: try: # 1. 解析Harness传来的输入 item_code = payload.get("item_code") warehouse_id = payload.get("warehouse_id", "WH_MAIN") # 2. 从连接池获取连接（非阻塞） conn = oracle_pool.acquire(timeout=5) # 超时5秒，避免卡死 # 3. 执行查询（注意：这里必须用硬编码SQL，不能拼接！防注入） cursor = conn.cursor() cursor.execute(""" SELECT quantity_on_hand, reserved_quantity FROM inventory_balance WHERE item_code = :item AND warehouse_id = :wh """, item=item_code, wh=warehouse_id) row = cursor.fetchone() # 4. 构建Harness要求的输出格式 result = { "output": { "available": row[0] - row[1] if row else 0, "total": row[0] if row else 0, "warehouse": warehouse_id }, "metadata": { "query_time_ms": int((time.time() - start_time) * 1000), "db_connections_used": oracle_pool.opened } } except Exception as e: result = { "error": str(e), "metadata": {"error_type": type(e).__name__} } finally: if 'conn' in locals(): oracle_pool.release(conn) # 必须归还连接！ return result # 主服务（Flask轻量级） from flask import Flask, request, jsonify app = Flask(__name__) @app.route('/health', methods=['GET']) def health(): return jsonify({"status": "ok", "version": "1.2.0"}) @app.route('/invoke', methods=['POST']) def invoke(): payload = request.get_json() start_time = time.time() result = handle_request(payload) return jsonify(result) if __name__ == '__main__': init_oracle_pool() app.run(host='0.0.0.0', port=8080, threaded=False) # 关键：threaded=False，Harness自己管并发配套的skill.yaml（必须和代码放同一目录）：
name: "erp_inventory_check" version: "1.2.0" description: "查询ERP系统库存余量" resource_profile: cpu: 2.0 memory: "2Gi" gpu: false concurrency: 3 # 这个值必须和oracle_pool.max一致！ endpoints: health: "http://localhost:8080/health" invoke: "http://localhost:8080/invoke"实操心得：Skill的
concurrency参数是性命攸关的数字。我们曾设为10，结果Oracle连接池爆满，整个ERP系统被拖垮。正确算法是：concurrency = min(Oracle最大连接数 / Skill实例数, 单实例CPU核数)。我们测试发现，A100单实例跑3个并发最稳，再多就触发显存碎片化。
3.3 Harness调度器配置：让3200 QPS不抖的六个关键参数
Harness调度器的config.yaml不是随便填的，每个参数都经过压测校准。以下是我们的生产配置（删减注释版）：
# config.yaml server: host: "0.0.0.0" port: 9000 grpc_port: 9001 # 资源调度核心（这才是高并发的灵魂） scheduler: # 1. 任务队列深度：太小会丢请求，太大吃内存 queue_size: 10000 # 按3200 QPS * 3秒缓冲期计算得出 # 2. GPU资源分片粒度：A100显存100GB，按4GB切片 gpu_shard_size: "4Gi" # 必须整除总显存，否则浪费 # 3. 抢占式调度开关：开启后，高优先级Agent可中断低优先级 preemptive_scheduling: true # 4. 自适应超时：根据历史P95延迟动态调整 adaptive_timeout: enabled: true base_timeout_ms: 5000 p95_window_seconds: 60 # 5. 技能熔断器：连续3次失败，自动降级到fallback circuit_breaker: failure_threshold: 3 reset_timeout_seconds: 60 # 6. 内存回收策略：防止Skill内存泄漏拖垮整个节点 memory_reclaim: enabled: true threshold_percent: 85 # 内存使用超85%，强制重启最老Skill实例参数背后的血泪教训：
queue_size: 10000：我们试过5000，晚高峰时出现queue full错误，用户请求直接503；试过20000，内存占用飙升到32GB，GC频繁导致延迟毛刺。10000是平衡点。gpu_shard_size: "4Gi"：DeepSeek-R1-GGUF量化后约3.2GB显存，留0.8GB缓冲刚好。设成2Gi会切太多片，调度开销大；设成8Gi，一块A100只能跑12个Skill，资源利用率不足60%。adaptive_timeout：固定超时很危险。ERP查询平时200ms，但月底结账时可能飙到4500ms。开启自适应后，系统自动把超时提到5200ms，避免误杀正常请求。
3.4 SSE流式输出与Abort机制：让用户感觉“真在思考”
用户最讨厌白屏等待。我们用SSE（Server-Sent Events）实现大模型回答的实时渲染，但关键是如何安全Abort：
# model_skill.py（DeepSeek-R1 GGUF调用） from llama_cpp import Llama from flask import Response, stream_with_context import json import threading llm = Llama( model_path="./models/deepseek-r1.Q4_K_M.gguf", n_ctx=4096, n_threads=8, n_gpu_layers=45, # A100全显存加载 verbose=False ) def generate_stream(prompt: str): # 1. 创建生成器，yield每个token for token in llm(prompt, stream=True, temperature=0.7): yield f"data: {json.dumps({'token': token['choices'][0]['text']})}\n\n" yield "data: [DONE]\n\n" @app.route('/stream', methods=['POST']) def stream_response(): payload = request.get_json() prompt = payload.get("prompt", "") # 2. 关键：用threading.Event实现Abort信号 abort_event = threading.Event() # 3. Harness会发SIGTERM，我们捕获并设置abort_event def signal_handler(signum, frame): abort_event.set() signal.signal(signal.SIGTERM, signal_handler) # 4. 流式响应，每次yield前检查abort_event def generate(): for chunk in generate_stream(prompt): if abort_event.is_set(): yield "data: {'error': 'aborted'}\n\n" break yield chunk return Response( stream_with_context(generate()), mimetype="text/event-stream", headers={"Cache-Control": "no-cache", "Connection": "keep-alive"} )前端JS监听Abort：
// 用户点击停止按钮时 const controller = new AbortController(); fetch('/api/stream', { method: 'POST', body: JSON.stringify({prompt: "..." }), signal: controller.signal // 传递AbortSignal }).then(r => r.body.getReader()).then(reader => { const read = () => reader.read().then(({done, value}) => { if (done) return; const text = new TextDecoder().decode(value); // 处理SSE数据... read(); }); read(); }); // 用户点击停止 document.getElementById('stop-btn').onclick = () => controller.abort();注意：
controller.abort()会触发fetch的signal，进而发送SIGTERM给后端进程。我们的Skill必须在3秒内响应，否则Harness会强制kill。这就是为什么skill.yaml里必须设graceful_shutdown_seconds: 3。
4. 高并发压测与问题排查：3200 QPS下的真实故障现场还原
4.1 压测方案设计：拒绝“Hello World”式假压测
很多教程用ab -n 10000 -c 1000压一个/health接口，这毫无意义。我们的真实压测方案：
流量模型：用Locust模拟三种真实用户行为：
- 60%：IM消息解析（轻量，CPU密集，平均耗时120ms）
- 25%：ERP库存查询（中量，IO密集，平均耗时2400ms）
- 15%：合同条款比对（重量，GPU密集，平均耗时3800ms）
数据构造：所有请求带真实业务参数：
- IM消息：随机生成含emoji、URL、乱码的200字符文本；
- ERP查询：从10万SKU库中随机选code，warehouse_id轮询；
- 合同比对：用真实PDF转文本（每份12页，含表格和签名区）。
指标监控：不止看QPS和延迟，重点盯三个黄金指标：
scheduler_queue_length：超过5000说明调度器瓶颈；skill_gpu_memory_utilization：单卡超95%触发熔断；agent_state_transition_rate：每秒Agent状态变更次数，突降说明卡死。
压测脚本核心片段（locustfile.py）：
class AgentUser(HttpUser): @task def im_parse(self): self.client.post("/invoke", json={ "skill": "im_message_parser", "input": {"message": random_im_message()} }, timeout=5.0) # 显式设超时，避免hang住 @task(3) # 权重3，实际占比25% def erp_check(self): self.client.post("/invoke", json={ "skill": "erp_inventory_check", "input": {"item_code": random_sku(), "warehouse_id": random_wh()} }, timeout=6.0) @task(2) # 权重2，实际占比15% def contract_compare(self): self.client.post("/stream", json={ "prompt": f"对比以下两份合同条款：{random_contract_pair()}" }, timeout=10.0, stream=True)4.2 故障排查速查表：我们遇到的七类典型问题及根因
| 问题现象 | 监控指标异常 | 根本原因 | 解决方案 | 验证方式 |
|---|---|---|---|---|
| QPS卡在1800不再上升 | scheduler_queue_length持续>8000，cpu_usage<40% | 调度器线程数不足，默认4线程无法处理高并发任务队列 | 修改config.yaml：scheduler.threads: 16 | 重启后queue_length回落至<2000 |
| GPU显存缓慢上涨，24小时后OOM | skill_gpu_memory_utilization从70%→98%单向爬升 | Skill未正确释放llama.cpp context，llm.__del__()没被调用 | 在Skill退出前显式调用llm.close()，并在atexit注册清理函数 | OOM周期从24h延长至>7天 |
| ERP查询P99延迟从2400ms→5200ms | skill_db_connection_wait_time_msP95>3000ms | Oracle连接池max=3，但并发请求峰值达5，导致排队 | 将skill.yaml中concurrency从3改为5，并同步调大Oracle连接池 | 延迟回归2400ms±200ms |
| SSE流式响应偶发中断 | http_requests_total{code="502"}突增 | Nginx默认proxy_read_timeout=60s，但合同比对需3800ms | 在Nginx配置中加proxy_read_timeout 4000; | 中断率从5%降至0.1% |
Agent状态卡在running不更新 | agent_state_transition_rate骤降为0 | Skill进程崩溃但Harness未收到退出信号，僵尸进程占资源 | 在Skill启动脚本中加exec "$@"确保信号透传 | 状态更新延迟<100ms |
| 多用户同时请求时答案错乱 | llm_output_tokens_total突增200% | llama.cpp的llm实例被多个线程共享，context污染 | 每个Skill进程只初始化一个llm，禁用多线程调用 | 输出准确率回归99.98% |
| Harness调度器CPU飙升100% | scheduler_cpu_usage>95% | Policy DSL里写了无限循环（如while true: call skill） | 用harness validate-policy policy.yaml静态检查 | CPU回落至35% |
独家技巧：我们写了个
harness-debug工具，一键抓取当前所有Agent的完整状态树：./harness-debug --dump-state > state_dump.json # 输出包含每个Agent的Skill调用链、资源占用、最后心跳时间这比翻日志快10倍。有一次发现某个Agent的
last_heartbeat是3小时前，直接定位到Skill进程已死但Harness没感知——原因是Skill用了os._exit(0)而非sys.exit(0)，信号没传出去。
4.3 生产环境调优实录：从2200 QPS到3200 QPS的三次关键升级
第一次升级：GPU显存碎片整理（+300 QPS）
问题：A100显存100GB，但nvidia-smi显示只用了72GB，free -h却报告GPU内存不足。
根因：llama.cpp的CUDA allocator产生碎片，连续分配/释放小块显存后，大块无法合并。
解法：在model_skill.py里加显式内存整理：
import torch # 每次生成前清空缓存 torch.cuda.empty_cache() # 强制CUDA allocator整理碎片 torch.cuda.synchronize()效果：显存可用率从72%→91%，多跑出3个Skill实例。
第二次升级：数据库连接池预热（+400 QPS）
问题：压测开始时前10秒P99延迟飙升，之后回落。
根因：Oracle连接池初始为空，首波请求要逐个建连。
解法：Skill启动时预热连接：
def init_oracle_pool(): global oracle_pool # ... 初始化代码 ... # 预热：立即建立min个连接 for _ in range(oracle_pool.min): oracle_pool.acquire() oracle_pool.release()效果：首波延迟毛刺消失，整体P99下降320ms。
第三次升级：SSE响应头优化（+200 QPS）
问题：SSE流式响应在Chrome里偶发卡顿。
根因：Nginx默认proxy_buffering on，会缓存SSE数据块，破坏实时性。
解法：Nginx配置加两行：
location /stream { proxy_buffering off; proxy_cache off; }效果：前端渲染延迟从平均120ms→45ms，用户感知明显更“丝滑”。
5. 项目落地经验与避坑指南：给想动手的同行一句实在话
5.1 技术选型避坑：别被“最新最热”带偏节奏
看到标题里“最新最细最全”，很多人会冲动去追harness 0.9.0-alpha或deepseek-harness-plugin。我劝你冷静。我们团队试过0.9.0-alpha，结果发现它把Skill资源声明从YAML挪到了gRPC Schema里，导致所有现有Skill要重写。更糟的是，它的Abort机制有竞态条件Bug，用户点停止后，GPU显存有时不释放。最后我们退回0.8.3稳定版，用patch方式补了Abort逻辑——生产环境永远选Last Stable Release，不是Latest Release。
同样，“android app集成ai大模型gguf”这种需求，别急着找现成SDK。我们给移动端做的方案是：App只负责采集语音/图片，上传到Harness Agent服务，服务端用whisper.cpp转文本、llama.cpp推理，再把结构化结果推回App。这样App体积<5MB，不用打包GB级模型，OTA更新也快。强行把GGUF塞进APK，光模型下载就卡死一半用户。
5.2 团队协作红线：三个绝对不能妥协的规范
Skill必须带单元测试：每个Skill的
test_skill.py要覆盖边界情况。比如ERP Skill必须测item_code=""、warehouse_id="INVALID"、网络超时三种case。我们用pytest写，覆盖率必须≥85%，CI不通过禁止合入。曾经有个同事跳过测试，结果上线后遇到空SKU码，直接返回None导致前端崩溃——这本该在测试里暴露。Policy变更必须双人复核：任何修改
policy.yaml的操作，必须由架构师+业务方共同签字。Policy是Agent的“宪法”，改错一行可能让整个销售流程失效。我们用Git Hooks强制检查：git commit时自动运行harness validate-policy，失败则拒绝提交。GPU资源申请必须书面审批：每个Skill声明的
gpu: true，都要附上显存占用实测报告（用nvidia-smi dmon -s u跑10分钟）。曾经有团队为“保险起见”把所有Skill都标gpu: true，结果A100被占满，ERP查询被迫降级到CPU，延迟暴涨10倍。现在规则是：没测不准标GPU。
5.3 本地开发提效技巧：让新手30分钟跑通Hello World
别一上来就搞分布式。我们给新人的快速启动包：
- 下载
harness-quickstart.zip（含预编译Harness二进制、最小化Skill模板、docker-compose.yml）； docker-compose up -d，自动启动Harness调度器+PostgreSQL（存Agent状态）+Redis（作缓存）；cd skills/echo-skill && make run，启动一个打印输入的Skill；curl -X POST http://localhost:9000/api/v1/agents -d '{"skill":"echo-skill","input":{"msg":"hello"}}'，看到返回{"output":"hello"}即成功。
这个流程30分钟搞定。所有依赖都打包好了，连CUDA都不用装——因为Skill用CPU跑。等他理解了Agent/Skill/Policy的关系，再让他切到GPU版DeepSeek Skill。先建立认知闭环，再叠加复杂度，这是少走弯路的关键。
最后说句掏心窝的话：所谓“高并发”，从来不是比谁QPS数字大，而是比谁在流量洪峰下依然能让每个用户得到确定性的服务体验。我们这套Harness Agent系统，上线半年没出过P0故障，不是因为技术多炫，而是把每一个“可能出错”的环节，都用可验证的代码、可量化的参数、可追溯的日志，钉死了。你现在看到的每一条配置、每一行代码、每一个参数值，背后都是至少三次线上故障换来的教训。如果这篇笔记能帮你少踩一个坑，那它就值了。
