2026-10-13 Jay 下午研究草稿 — Agent 工程产品 + 生产部署命令

检索范围: CSDN 高价值技术分享 + Substack AI engineering newsletter 检索时间: 2026-10-13 12:20 (UTC+8) 本实例: Jay

一、Substack 高价值条目（2026年10月）

1. Make Your Coding Assistant a 10x AI Engineer — agent-engineer 插件实测

作者: Sarthak Rastogi
发布时间: 2026-10-12
可信度: 高——作者自建 A/B 对比实验，有 blinded grading 和 checklist

核心内容:

作者发布 agent-engineer 开源插件（兼容 Claude Code、Codex CLI、Cursor、OpenCode、 Gemini CLI），为编码 Agent 增加 senior AI engineer 技能。插件架构：

  • 11 项技能（Skills）：以 Markdown 文件承载，按需加载，包含 checklist 和决策规则
  • 4 个子代理（Subagents）：隔离执行大规模 trace 分析等洪水级任务
  • 5 个钩子（Hooks）：Python 脚本，绑定 session 事件，自动触发技能匹配、阻止 API key 外泄等

A/B 测试结果（6 项任务，Claude Code Opus 5.5，blinded grading，3轮/任务）：

任务 有插件达成率 无插件达成率
6 项综合 53% 34%
- 退款任务：插件组自动加 per-refund + daily cap，两次用了 idempotency key；无插件组有一次未验证即声称"100% accuracy"
- 分类任务：插件组先写 keyword-matching 模拟测试并声明准确率，被 eval gate 拦截并在最终消息自我纠正
- 便宜模型切换：插件组明确给出 eval 命令；无插件组直接声称 Haiku"足够"但无任何测量

分层诊断路由（Router Skill）：

插件按故障层级匹配技能，只在证据显示简单层失效时才升级：

Layer 0: 工具调用层（API/SDK 问题）
Layer 1: Prompt/上下文层
Layer 2: Agent 行为层（规划/推理）
Layer 3: 系统架构层（多 Agent/记忆/编排）

核心工程洞察：

  • agent-evals 技能要求：先做 error analysis + failure taxonomy，再写 judge；优先用代码检查而非 LLM judge；每个 judge 要用人标验证；多次运行才有统计意义；挂 CI
  • agent-observability 要求：每个 LLM call 和 tool call 一个 span，按 OpenTelemetry GenAI convention 记录；prompt 和 email 内容视为 PII
  • agent-guardrails 核心问题：是否同时具备"访问私有数据 + 暴露于不可信内容 + 对外通信"三个条件？是则攻击者可实施注入；移除任一条件可破解放大攻击

建议分类: agent / coding-agents / eval / production / open-source

后续行动: 建议精读插件源码 eval 模块实现（evals/ab/ 目录），评估接入 CI 的可行性

2. AI Agents Are Distributed Systems: 8 Patterns Every Engineer Should Know

作者: Arslan Ahmad (Design Gurus)
发布时间: 2026-10-04（付费内容）
可信度: 高——分布式系统经典教材体系迁移到 Agent 场景

核心洞察：将 AI Agent 定义为分布式系统：LLM 是远程慢服务，工具是其他远程服务，中间靠循环连接，维护状态。

8 大模式（附故障模式）：

模式 机制 Agent 中的典型失败
Retry + Backoff + Jitter 指数退避 + 随机 jitter Retry storm（所有 Agent 同时重试）；嵌套重试（SDK 3次 × wrapper 5次 × orchestrator 3次 = 45次）
Idempotent Tool Calls 每个副作用调用带幂等 key（基于 run ID + step，模型不参与生成） Key TTL < agent 最大运行时间时，恢复后重试会重复操作
Saga + Compensating Actions 多步骤配补偿操作，逆序回滚；补偿由 orchestrator 而非 LLM 决定 邮件/支付等不可逆操作如不在最后，人类审批前置
Circuit Breaker 失败率超阈值时快速熔断 Agent 无熔断时，单个工具慢导致整条链路超时
Timeout 每个网络调用设 timeout Agent 等待 LLM 响应时间不设上限
Queue + Token Budget 请求排队 + token 预算控制成本 Agent loop 失控导致无限 token 消耗
Distributed Tracing 每个 LLM call 和 tool call 记录 span，含 token 用量 无 tracing 时无法定位哪个工具失败
Rate Limiting 调用方限速，被调用方返回 429 时退避 Agent 对 429 响应不当导致永久阻塞

关键工程结论： - "模型决定步骤，orchestrator 决定补偿"——失败路径不能有非确定性组件 - Retry 只用于读操作；副作用操作必须幂等 - 多层重试叠加是灾难：只在单层配置

建议分类: agent / distributed-systems / production / reliability

二、CSDN 高价值条目

1. vLLM 生产化部署：负载均衡、监控与高可用架构

评价: ⭐⭐⭐⭐
类型: 生产级部署 / 运维实践
平台: CSDN博客
工程价值: 高——从"能跑"到"稳跑"的完整方案，涵盖 Nginx/Layer 4/Layer 7 代理配置、Keepalived VIP 漂移、健康检查四层体系、监控告警闭环

核心内容： - 三种部署模式：单机 API / 多机分布式 / Kubernetes 容器化 - 负载均衡策略：轮询（Round Robin）、权重、最小连接、IP Hash - 高可用方案：多副本 + 负载均衡消除单点；解耦 WebUI 与推理层；用 vLLM/Triton 提升吞吐 - 监控体系：GPU 利用率 + 显存 + 请求排队 + TTFT + TPOT 全链路可观测 - 安全：生产环境必须启用鉴权 + 访问控制

涉及命令:

# Layer 7 (HTTP) 代理配置片段
upstream vllm_backend {
    server 10.0.0.1:8000 weight=3;
    server 10.0.0.2:8000 weight=2;
    ip_hash;
}

建议分类: inference-engineering / vllm / production / ha

2. 大模型推理部署实战：压测 / PD分离 / 长上下文 / MoE / LoRA / KV量化命令集

评价: ⭐⭐⭐⭐⭐（命令密度极高，可复现性强）
类型: 工程实战 / 命令参考
发布日期: 2026-06-10
工程价值: 高——大量真实命令和阈值参数，覆盖 vLLM/SGLang 横评、PD 分离、MoE EP/EPLB、LoRA 动态切换、KV 量化

核心内容速览：

压测 SOP（六步法）:

# Step 1: 空载基线（5-10分钟）
# Step 2: 固定输入输出长度，逐步加并发 1/2/4/8/16/32/64
# Step 3: 换真实数据集（ShareGPT 或业务日志采样）
# Step 4: 阶梯加 QPS，每级 2-5 分钟
# Step 5: 找到 P99 TTFT 或排队时间明显上升的拐点
# Step 6: 用拐点的 70-80% 做 1 小时稳定性压测

vLLM 压测命令:

vllm bench serve \
  --model /models/Qwen2.5-7B-Instruct \
  --dataset-name sharegpt \
  --num-prompts 1000 \
  --request-rate 10 \
  --endpoint /v1/completions

SGLang 压测命令:

python -m sglang.bench_serving \
  --backend sglang \
  --host 127.0.0.1 --port 8000 \
  --dataset-name sharegpt \
  --num-prompts 1000 \
  --request-rate 10

关键监控指标:

vLLM:  vllm:num_requests_waiting / vllm:gpu_cache_usage_perc /
       vllm:e2e_request_latency_seconds / vllm:time_to_first_token_seconds /
       vllm:time_per_output_token_seconds

SGLang: sglang:num_running_requests / sglang:num_queueing_requests /
        sglang:cache_hit_rate / sglang:time_to_first_token_seconds

PD 分离命令:

# vLLM（实验性）
vllm serve model --role prefill --kv-transfer-method nccl
vllm serve model --role decode  --kv-transfer-method nccl

# SGLang 也在做 disaggregated serving 相关能力
# 注意：DP Attention ≠ PD 分离

max-model-len 场景化配置:

--max-model-len 8192     # 常规客服 / 简单问答
--max-model-len 32768    # RAG / 长文档摘要
--max-model-len 131072   # 代码仓库 / 超长文档，谨慎开

长上下文 KV Cache 控制手段对比:

手段 作用 代价
降 max-model-len 直接减少 KV 上限 输入长度受限
Chunked Prefill 长 prompt 不堵 decode 不能减少总 KV
FP8 KV Cache KV 显存约减半 少数任务精度影响
Prefix Caching 重复前缀可复用 需请求前缀稳定
CPU/SSD Offload 显存不够时用内存/磁盘兜底 延迟上升
Token 级压缩 H2O/SnapKV/StreamingLLM 对质量有影响

MoE EP + EPLB 命令（SGLang）:

python3 -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3-0324 \
  --tp 8 --ep 8 \
  --moe-a2a-backend deepep \
  --deepep-mode auto \
  --enable-dp-attention \
  --enable-eplb \
  --trust-remote-code \
  --dist-timeout 3600

MoE EP + EPLB 命令（vLLM）:

vllm serve deepseek-ai/DeepSeek-V3-0324 \
  --tensor-parallel-size 1 \
  --data-parallel-size 8 \
  --enable-expert-parallel \
  --enable-eplb \
  --eplb-config '{"window_size":1000,"step_interval":3000,"num_redundant_experts":2,"log_balancedness":true}'

LoRA 动态切换命令（vLLM）:

vllm serve /models/Qwen2.5-7B-Instruct \
  --enable-lora \
  --lora-modules cs=/loras/customer_service med=/loras/medical law=/loras/legal \
  --max-loras 8 \
  --max-lora-rank 64

LoRA 常见问题处理:

问题 表现 处理
rank 不一致 加载失败或显存超预期 max-lora-rank 设成最大 rank
LoRA 太多 显存碎片、冷启动慢 固定上限，热门 LoRA 预加载
batch 混 LoRA 吞吐下降 高吞吐业务按 LoRA 分流
权限混乱 业务 A 调到业务 B 的 LoRA API 层白名单隔离

KV Cache 量化命令:

# vLLM
vllm serve model --kv-cache-dtype fp8_e5m2

# SGLang
python3 -m sglang.launch_server \
  --model-path model --kv-cache-dtype fp8_e5m2

KV 量化适用场景:

场景 是否建议
8K 以下短请求 不一定，先看显存压力
32K-128K 长上下文 值得开，收益明显
H100/H200/B200 更适合，硬件支持 FP8
A100/L40S 取决于框架实现和性能回退
数值敏感任务 必须做质量回归

建议分类: inference-engineering / vllm / sglang / production / benchmark / moe / lora / kv-cache

3. SGLang 从0到1完整部署教程 + FastAPI 调用封装

评价: ⭐⭐⭐⭐
类型: 部署教程 + API 网关
平台: AMD 开发者社区（CSDN 兄弟站）
工程价值: 高——FastAPI + SGLang 生产网关完整代码（鉴权/限流/日志/监控/流式输出）

核心内容： - SGLang 安装（pip / 源码编译两种方式） - 启动参数详解表（含 --dp / --mem-fraction-static / --max-total-tokens 等） - FastAPI 网关完整代码：Bearer Token 鉴权 + 非流式/流式两种接口 + 健康检查 + SSE 格式 - 常见问题：CUDA OOM / NCCL / 模型名不匹配

FastAPI gateway 要点:

# 鉴权中间件
def verify_api_key(authorization: str = Header(default="")):
    if authorization != f"Bearer {API_KEY}":
        raise HTTPException(status_code=401)

# 流式响应 SSE 格式
async def event_generator():
    async with httpx.AsyncClient(timeout=120) as client:
        async with client.stream("POST", url, json=payload) as resp:
            async for line in resp.aiter_lines():
                if line.startswith("data: "):
                    yield f"{line}\n\n"

# 启动
uvicorn main:app --host 0.0.0.0 --port 8000 --reload

建议分类: inference-engineering / sglang / fastapi / production / api-gateway

三、综合工程建议

生产 vLLM/SGLang 部署检查清单

□ 压测基线：空载 TTFT / TPOT（5-10分钟）
□ 渐进并发：1→2→4→8→16→32→64，找拐点
□ max-model-len 按场景分级（8K / 32K / 131K）
□ KV 量化：长上下文场景开 FP8 e5m2，H100+ 硬件
□ MoE 部署：EP + EPLB，DeepEP 后端要求 ep_size = tp_size
□ LoRA 多租户：按业务线分流，API 层做白名单隔离
□ PD 分离：vLLM 实验性参数，生产评估需充足测试
□ 高可用：多副本 + Nginx/Layer 4 负载均衡 + Keepalived
□ 监控体系：TTFT / TPOT / 排队数 / GPU Cache 使用率 / Token Budget
□ FastAPI 网关：鉴权 + 限流 + 日志 + 流式输出
□ Circuit Breaker / Timeout / Retry Policy（见上方分布式模式）
□ Eval CI Gate：每次 prompt 变更必须跑 eval 对比

Substack 两条高质量线索

  1. agent-engineer 插件（Oct 12）：A/B 测试设计严谨，可作为 Agent eval 模块的参考实现；建议跟踪 evals/ab/ 目录结构
  2. 8 大分布式系统模式（Oct 4）：将经典分布式可靠性模式迁移到 Agent 场景，是 SWE interview + 生产系统设计的高价值素材

四、建议写入路径

写入路径: /shared/research-kb/inbox/jay/2026-10-13-jay-production-agent-engineering-oct-pm.md

草稿状态: ✅ 已写入

是否需要精读: - agent-engineer 源码 evals/ab/ 分支 → 评估 eval CI 接入可行性 - PD 分离实验参数 → 需要官方文档核验稳定性 - FastAPI + SGLang 网关代码 → 适合直接复用到内部平台

建议主题页更新: - inference-engineering: 增加生产 HA 架构检查清单 + PD 分离状态标记 - agent-production: 增加分布式系统 8 大模式 + Agent eval CI 最佳实践 - sglang: 增加 FastAPI 网关模板参考