工程手册

0. 事实基线（先纠正，再据此备赛）

0.1 对委托说明的四处修正（重要）

1. "航天科技集团一院科技委主办"不准确：公开通知中主办单位是中国指挥与控制学会，中国运载火箭技术研究院（航天科技集团一院）是承办单位之一，未见"科技委"作为主办方的公开表述。
2. "2025-12-03 南京大学苏州校区"需放宽：公开通知表述为总决赛12月2日至6日在苏州市举办；南京大学苏州校区国际交流中心是主体赛报到点，专项赛报到点为苏州纽威丽筠酒店。
3. "≤35B 模型上限"未在公开通知中找到出处：通知只写"大模型提示词+大小模型协同"，没有公开的参数量上限条款。本文按"≤35B 是可工程落地的私有化档位"组织，但请以当届赛题/技术文件为准，不要当作既定规则。
4. 官方《远程协同打击攻防博弈挑战赛智能体开发指南》PDF 曾被搜索引擎索引（路径形如 /uploads/article/20250820-4/...智能体开发指南.pdf），本次直连返回 404（站点改版）。备赛请以站点"资料专区/平台下载"内当届文件为准：hiai.ciccwargame.com。

0.2 相关公开学术参考（方法来源，非赛题）

1. ≤35B 模型私有化部署

1.1 主流开源模型与规模档（均为公开权重）

Qwen3 官方部署建议：服务端推荐 SGLang / vLLM；本地/边缘推荐 Ollama、LMStudio、MLX、llama.cpp、KTransformers（Qwen3 博客）。官方另说明 Qwen3 支持"思考/非思考"双模式，可用于思考预算控制——这在需要硬时限的回合制对抗中是关键工程杠杆。

1.2 推理引擎对比

1.3 量化方案对比

1.4 显存估算（工程公式，非官方数字）

权重显存 ≈ 参数量 × 每参数字节
           BF16=2 | FP8/INT8=1 | INT4(AWQ/GPTQ)≈0.55
KV Cache ≈ 2 × layers × kv_heads × head_dim × seq_len × batch × dtype_bytes
           （GQA 下 kv_heads 远小于 q_heads；Qwen3 多为 8 或 4）
总显存 ≈ 权重 + KV + 激活/框架开销(约 10~20%)，再留 ≥15% 余量
注意：MoE 必须按【总参数】加载权重，按【激活参数】估计算力开销。

按档位的粗略落位（估算，仅用于选型讨论）：

1.5 上下文、吞吐与并发调参

2. 战前部署阶段工程：自然语言任务书 → 结构化想定

2.1 五段式流水线

任务书(自然语言)
  → [1] 抽取：LLM + JSON Schema 约束解码 → 结构化意图
  → [2] 求解：约束满足(CSP) / 组合优化 → 部署与挂载候选
  → [3] 校验：硬约束检查 + 可行性模拟
  → [4] 修复：违规项回灌 LLM 定向重写（最多 N 轮）
  → [5] 提交：生成平台指令序列 + 人读理由书

核心原则：LLM 只负责"翻译与建议"，不负责"合法性"。 一切数值边界、数量上限、坐标范围由确定性代码裁决。

2.2 Schema 设计（示例骨架，字段名按当届接口调整）

{
  "schema_version": "1.0",
  "mission_id": "string",
  "intent": {
    "objective": "enum: 突击|封锁|护航|存在",
    "deadline_tick": "integer >= 1",
    "priority_targets": [{"id": "string", "weight": "number 0..1"}],
    "constraints": {
      "no_go_zones": ["string"],
      "max_loss_tolerance": "number 0..1",
      "min_standoff": "number"
    }
  },
  "units": [{
    "unit_id": "string",
    "platform_type": "string",
    "role": "enum: 侦察|干扰|打击|支援",
    "position": {"x": "number", "y": "number", "z": "number"},
    "heading": "number",
    "loadout": [{"weapon_id": "string", "qty": "integer >= 0"}],
    "rules_of_engagement": "enum: 自卫|受令|自主",
    "confidence": "number 0..1"
  }],
  "provenance": [{"field": "string", "from": "quote|default|rule", "evidence": "string"}]
}

Schema 设计六条军规

1. 枚举优先于自由文本：能枚举的字段绝不用 string，否则下游必然出现幻觉取值。
2. 每个数值字段带 min/max：模型无法越界输出。
3. 必填字段尽量少：缺失字段交给默认值表补，而不是让模型硬猜。
4. 加 provenance 字段：便于赛后归因"这条结论是任务书原文、默认值、还是模型编的"。
5. 要有 confidence：低置信字段进入"待人工确认"队列（决赛阶段正好由人以自然语言微调）。
6. schema 版本化：schema_version + 迁移脚本，避免平台升级后全线崩。

实现手段：约束解码（vLLM guided_json / SGLang JSON Schema），从机制上保证输出可解析（vLLM 结构化输出 已核实）。

2.3 约束求解与部署位置规划

分工建议：让 LLM 提出 3–5 套候选方案 + 每套的定性理由，让求解器给出可行解与目标值，最终由确定性的打分函数选一套提交，而不是让 LLM 直接投最终解。

2.4 挂载组合优化

建模为多目标背包：

• 硬约束：挂点数量/类型、总重量、兼容矩阵（平台 × 弹种）、库存上限。
• 目标（加权和或帕累托）：任务适配度、冗余度、消耗成本、与交战规则（ROE）的一致性。
• 输出：候选集合 + 帕累托前沿，而不是单一"最优解"——对手行为未知时，保留可切换方案更有价值。
• 求解：变量规模小（通常几十个）→ 整数规划或穷举 + 剪枝即可，无需重型求解器，利于离线复现。

2.5 可行性校验（提交前必过的门）

3. 战中决策阶段工程

3.1 提示词工程（"选手即 AI 教练"）

提示词模板骨架

[角色] 你是 …（一句话职责）
[输入] 当前 tick、态势摘要（结构化）、可用动作集合、约束清单
[约束] 1) … 2) … 3) 输出必须是合法 JSON，取值必须来自给定枚举
[决策规则] 优先级：… ；无可行动作时输出 {"action":"hold"}
[输出] 严格按 schema（内联给出）
[样例] 2 个输入→输出对

3.2 知识库与 RAG

工程红线：检索不到就明确返回"未检索到"，绝不允许模型自由发挥补全——这是回合制对抗中最常见的塌缩来源。

3.3 大小模型协同工作流

态势输入
  → [小模型/规则] 数值特征抽取、聚类、异常检测、候选动作枚举   ← 快、确定性、可测
  → [大模型] 意图理解 + 方案生成 + 冲突裁决                    ← 慢、贵、每 tick 限量
  → [确定性校验器] schema + 约束 + 可行性                      ← 硬门槛
  → [执行] 微服务调用平台指令接口
  → [回传] 结果结构化落库 → 生成下一 tick 摘要
  → [大模型] 仅在触发条件满足时做滚动重规划

3.4 工具 / 微服务拆解与契约设计

契约设计要点

• 每个工具返回结构化结果 + 人类可读摘要双通道（见 §3.5）。
• submit_plan 必须带幂等键（tick + hash(plan)），重试不会重复提交。
• 错误码分类：RETRYABLE（网络/超时）与 FATAL（schema 违规）——前者重试，后者改提示词。
• 工具的 description 就是给模型的文档，要写清何时用、参数含义、返回结构。
• 工具集可按公开协议（如 Model Context Protocol）组织以便复用（通用协议，非本赛专用）。

3.5 态势摘要生成（双通道）

• 摘要要做增量压缩：只写"相对上一 tick 的变化"，否则上下文迅速溢出。
• 上下文预算：设 token 上限，历史按滑动窗口 + 周期归档（每 K tick 折叠成一段"历史小结"）。

3.6 滚动重规划 / 超时降级 / 幂等重试

触发重规划的条件（任一）：
  1) 关键事件（既定目标失效、单位损失超阈值、新目标出现）
  2) 距上次规划超过 K 个 tick
  3) 执行偏差超过阈值（计划预期 vs 实测）

三级降级：
  L0 大模型完整推理
  L1 大模型单次快答（非思考模式 / 缩短上下文 / 减少候选）
  L2 规则或查表策略（预置保守方案，保证必有提交）

超时预算：每 tick 设 wall-clock 预算，LLM 调用 ≤ 预算 60%，
          留出校验、提交与重试时间。
重试策略：指数退避 + 抖动；仅对 RETRYABLE 重试；超过 3 次转 L2。
幂等：所有写操作带 idempotency_key；服务端与客户端双去重。

4. 编排框架对比与选型

选型建议（回合制、硬时限、需复现）

1. 首选 LangGraph 或自研状态机：回合制 tick + 硬超时 + 必须复现，天然就是状态机而非自由对话。图/状态机能精确控制"这一 tick 最多调几次 LLM、超时走哪条分支"。
2. AutoGen 谨慎用：对话式多智能体会引入不确定轮数，难以保证时限；若用，必须限制 max_turns 并设终止条件。
3. CrewAI 适合快速原型与设计报告，上线前评估其调度开销。
4. Dify 适合低代码快速验证与演示，注意自定义微服务/超时控制/复现性的平台边界（Dify 文档）。
5. 多智能体不是越多越好：公开研究指出多智能体 LLM 系统的失败主要来自规格与协调缺陷而非模型能力（arXiv:2503.13657 已核实）。建议 2–3 个角色（规划 / 执行 / 校验）足够。
6. 跨框架公开评测亦指出混合设计常优于单一框架（IEEE 论文、微软学习模块：比较业务流程框架）。

5. 平台对接（通用工程形态）

5.1 常见对接形态

公开可查的同类平台交互相似性证据：官方"联合作战"赛道曾公开发布含 jsqlsim Python SDK、场景工具与引擎的压缩包，并在《智能体开发指南》中给出 api_get_contact_info(self, situation) 这类面向态势对象的方法式接口与动作参数枚举（如 mission_guid、avoid_contact、dive_on_threat）。参见被索引的指南 PDF：联合作战智能体开发指南（20240801）（本次直连 404，仅供检索线索，请以站点现状为准）。

5.2 指令 schema 与状态机

client_state: INIT → HANDSHAKE → DEPLOY → (LOOP: OBSERVE→DECIDE→VALIDATE→SUBMIT)
              → TERMINATED
每个状态定义：进入条件 / 允许动作 / 超时 / 失败降级 / 退出条件
所有出站指令：{tick, unit_id, action, params, idempotency_key, schema_version}
所有入站态势：先落盘原文（审计）→ 再解析（容错）→ 再进摘要层

5.3 可观测日志（强烈建议）

工程要求：日志异步落盘，绝不能因为写日志阻塞决策线程。

6. 自动化评测与实验方法

6.1 离线回放（最高性价比）

把历史对局的态势序列录制成数据集，让智能体在离线环境重放：

• 优点：快、便宜、可无限次跑、结果可比。
• 做法：录制 (tick, situation, ground_truth_action, outcome)；离线跑时用冻结的态势替换实时输入。
• 指标：动作合法率、与人类/基线动作一致率、计划可行性率、延迟。

6.2 消融实验（写进设计报告的硬通货）

每个消融至少 3 个随机种子，报 均值 ± 标准差，不要只报最好一次。

6.3 对手建模

• 基线对手：规则 BOT、平台内置 AI、上一版本自己的智能体（self-play 迭代）。
• 对手池：把不同风格的对手（激进/保守/随机）固定成评测矩阵，避免只对一种对手调优。
• 泛化检验：留出未参与调参的想定做最终测试。

6.4 随机种子与复现

• 推理侧：固定 seed + temperature（决策类建议低温度或贪心）。
• 求解侧：所有启发式/采样固定种子。
• 配置侧：config.yaml + 模型版本 + prompt 版本 + 库版本一并写入实验记录。
• 可复现是申诉与设计报告的证据基础。

6.5 A/B 指标

6.6 失败模式归因

对照 Why Do Multi-Agent LLM Systems Fail? 已核实 的框架建立失败分类表：

7. 备赛 Checklist

7.1 时间线

7.2 角色分工（6 人队典型）

7.3 风险清单

7.4 常见失分点速查

8. 来源与核实状态

赛事官方来源（已抓取核实）

• 中国指挥与控制学会《关于组织2025第九届全国兵棋推演大赛人机混合决策专项赛的通知》 <https://www.c2.org.cn/h-nd-2096.html>（镜像 <https://ciccwargame.com/h-nd-155.html>）
• 中国指挥与控制学会《关于组织2025第九届全国兵棋推演大赛总决赛暨第七届全国智能博弈论坛的通知》 <https://m.c2.org.cn/nd.jsp?groupId=24&id=2376&mid=353>
• 全国兵棋推演大赛专项赛赛区站点 <http://hiai.ciccwargame.com/>（已更新为 2026 第十届）
• 被索引但直连 404 的旧版《智能体开发指南》PDF 线索：hiai.ciccwargame.com/uploads/article/20250820-4/...智能体开发指南.pdf；《联合作战智能体开发指南（20240801）》：hiai.ciccwargame.com/uploads/article/20240801/...智能体开发指南.pdf

模型与推理（官方文档 / 官方博客）

• Qwen3 官方博客（规模/层数/上下文/许可/部署建议） <https://qwenlm.github.io/zh/blog/qwen3/>
• Qwen 官方文档 <https://qwen.readthedocs.io/zh-cn/stable/>
• vLLM <https://docs.vllm.ai/en/latest/>；量化 <https://docs.vllm.ai/en/latest/features/quantization/index.html>；结构化输出 <https://docs.vllm.ai/en/latest/features/structured_outputs.html>
• SGLang <https://docs.sglang.io/>
• TensorRT-LLM <https://nvidia.github.io/TensorRT-LLM/>
• llama.cpp <https://github.com/ggml-org/llama.cpp>

论文（arXiv 抓取返回 200 者标注"已核实"）

• PagedAttention / vLLM <https://arxiv.org/abs/2309.06180> 已核实
• SGLang <https://arxiv.org/abs/2312.07104> 已核实
• GPTQ <https://arxiv.org/abs/2210.17323> 已核实
• RAG 综述 <https://arxiv.org/abs/2312.10997> 已核实
• RAGAS <https://arxiv.org/abs/2309.15217> 已核实
• Lost in the Middle <https://arxiv.org/abs/2307.03172> 已核实
• Chain-of-Thought <https://arxiv.org/abs/2201.11903> 已核实
• ReAct <https://arxiv.org/abs/2210.03629> 已核实
• Plan-and-Solve <https://arxiv.org/abs/2305.04091> 已核实
• Self-Consistency <https://arxiv.org/abs/2203.11171> 已核实
• Few-Shot (GPT-3) <https://arxiv.org/abs/2005.14165> 已核实
• LLM-as-a-Judge <https://arxiv.org/abs/2306.05685> 已核实
• LLM Agent 综述 <https://arxiv.org/abs/2308.11432> 已核实
• 多智能体失败模式 <https://arxiv.org/abs/2503.13657> 已核实
• AgentBench <https://arxiv.org/abs/2308.03688> 已核实
• DeepSeek-V3 技术报告（FP8 实践） <https://arxiv.org/abs/2412.19437> 已核实

框架文档

• LangGraph <https://langchain-ai.github.io/langgraph/> 已核实
• AutoGen <https://microsoft.github.io/autogen/stable/> 已核实
• CrewAI <https://docs.crewai.com/> 已核实
• Dify <https://docs.dify.ai/> 已核实
• 微软：比较多智能体编排框架 <https://learn.microsoft.com/zh-cn/training/modules/aaai-implement-multi-agent-orchestration-azure-ai-foundry/6-compare-orchestration-frameworks>

说明与未核实项（务必自行复核）

• "≤35B 上限"未找到公开出处，请以当届技术文件为准。
• GLM / InternLM / DeepSeek-R1-Distill / Llama 的具体参数与上下文数字本次未能逐字核实（Hugging Face 域名在本环境不可达），表中标注"以模型卡为准"，正式材料请自行打开模型卡确认。
• 显存 / 吞吐估算为通用工程公式推导的区间，非任何官方数字，实际以压测为准。
• BGE Reranker 链接未逐字核实。
• 本文不包含任何战术运用、目标选择、毁伤效果或作战建议；涉及对抗的部分仅到"工程接口与流程"层级。

本文档由公开资料整理，用于工程与备赛方法论参考。赛事规则、接口与时限以主办方当届正式文件为唯一准绳。