做 AI 应用开发这几年，最大的感受是“Demo 很简单，上线很难”。
很多时候，一个基于 Prompt 的原型在本地跑得很顺畅，一旦放到生产环境，面对多变的输入、网络波动或业务逻辑变更，系统立刻变得不可预测。成本失控、幻觉频发、流程中断，这些不是模型的问题，是工程约束没跟上。
所谓的 Harness Engineering，本质上就是在概率性的模型之上，构建确定性的工程围栏。它不是简单的代码封装，而是一套分层治理体系。核心逻辑可以归纳为六层叠加：SPEC 定目标、Rule 设底线、Skill 固化流程、Sub-Agent 拆分角色、Workflow 编排协作、Script 客观验证。
这套架构不是为了炫技，而是为了在生产环境中获得可预期的交付能力。
一、控制层：SPEC 与 Rule 的硬约束
很多团队在搭建 Agent 时，习惯把期望直接写在 System Prompt 里，比如“请保持专业语气”、“不要输出敏感信息”。这种软性约束在流量上来后基本失效。
SPEC：意图的结构化定义
SPEC（Specification）层的目的是消除歧义。与其让模型猜用户想要什么，不如强制输入符合特定结构。
在生产系统中，入口不应是自由文本，而应是一个带有 Schema 校验的请求对象。如果用户输入无法满足最小可用场景的定义，直接在网关层拦截，而不是消耗 Token 去尝试修复。
// 示例：任务输入的 SPEC 定义
{
"task_type": "enum['code_review', 'deploy_check']",
"target_repo": "string (required)",
"priority": "number (1-5)"
}
这一步的价值在于将“模糊的自然语言请求”转化为“明确的任务指令”，后续的所有处理都基于这个确定的上下文进行。
Rule：底线的程序化实现
Rule 层是安全阀。这里的原则是：能写代码就别写提示词。
提示词里的规则容易被模型忽略，而代码里的规则是强制执行的。常见的 Rule 包括：
- 内容安全：正则匹配敏感词、PII 信息过滤。
- 资源限制：单次调用最大 Token 数、并发配额。
- 逻辑边界：禁止执行特定高危操作（如 rm -rf）。
在实际架构中，Rule 通常作为 Middleware 存在，位于 Router 和 Model 之间。一旦触发阻断规则，直接返回错误码，不进入推理链路。这比事后监控要有效得多，也节省了大量算力成本。
二、能力层：Skill 与 Sub-Agent 的解耦
当任务复杂度超过单轮对话的能力范围时，必须引入结构化拆解。这是从 Chatbot 走向 Agent 的关键分水岭。
Skill：原子能力的封装
Skill 不应该是一个巨大的函数，而应该是高内聚的工具包。例如“查询数据库”是一个 Skill，“生成报告”是另一个 Skill。
关键在于接口标准化。无论底层调用的是 SQL 还是 REST API，对上层而言，它们都应该遵循统一的 Input -> ToolCall -> Output 协议。这样做的收益是替换底层实现时，上层逻辑无需变动。
# 示意代码：Skill 注册机制
@skill_register(name="db_query", description="查询订单状态")
async def query_order(order_id: str) -> dict:
# 内部处理具体的 DB 连接、异常捕获
return await db.fetch_one(f"SELECT * FROM orders WHERE id={order_id}")
Sub-Agent：角色的垂直隔离
复杂场景下，一个全能 Agent 往往表现平庸。Sub-Agent 模式通过上下文隔离，让不同角色专注特定领域。
比如在一个运维场景中，可以拆分为：
- 诊断 Agent：只负责分析日志，无权执行命令。
- 执行 Agent：只负责执行脚本，需经过审批。
- 汇报 Agent：负责生成人类可读的总结。
这种拆分不仅是逻辑上的，更是权限上的。每个 Sub-Agent 拥有独立的 Context Window 和工具集。虽然这会增加通信开销，但显著降低了单个节点的认知负荷和出错率。
三、执行层：Workflow 与 Script 的闭环
有了规则和原子能力，如何保证它们按预期协作？这就需要编排和验证。
Workflow：确定性编排
LLM 的生成是不确定的，但业务流程必须是确定的。Workflow 层负责定义状态机或 DAG（有向无环图）。
- 串行：A 完成后触发 B。
- 并行：A 和 B 同时执行，结果汇聚给 C。
- 分支：根据判断结果选择不同路径。
使用状态机管理进度至关重要。当某个节点失败时，系统知道该重试、降级还是人工介入，而不是让整个会话崩溃。对于长尾任务，Workflow 的状态持久化是必须的，否则服务重启就丢了进度。
Script：客观验证与评估
最后也是最重要的一环，是如何知道这个系统好不好用？不能靠感觉，要看数据。
Script 层指的是自动化测试和评估脚本。它包含两部分：
- 单元测试：针对每个 Skill 和 Rule 的逻辑验证。
- Evals（评估）：针对端到端任务的自动化打分。
建立一套 Golden Dataset（黄金数据集），定期跑回归测试。如果新的 Prompt 优化导致旧案例准确率下降，自动报警。没有这一层，模型的迭代就是盲人摸象，线上事故无法避免。
四、架构权衡与落地建议
这套六层模型听起来很完美，但在实际落地中，每一层都在增加系统的复杂度。
| 层级 | 复杂度成本 | 核心价值 | 适用场景 |
|---|---|---|---|
| SPEC | 低 | 减少输入噪声 | 所有对外接口 |
| Rule | 中 | 安全与合规 | 涉及资金、数据修改 |
| Skill | 中 | 复用与维护 | 需要调用外部 API |
| Sub-Agent | 高 | 降低认知负荷 | 复杂多步骤任务 |
| Workflow | 高 | 流程可控性 | 长耗时、状态依赖任务 |
| Script | 高 | 质量保障 | 任何需要持续迭代的系统 |
几个关键的工程取舍：
- 过度设计风险：如果是简单的问答机器人，上全套 Sub-Agent 和 Workflow 是杀鸡用牛刀。优先从 SPEC 和 Rule 做起，随着业务变复杂再逐步叠加。
- 延迟代价：每多一层交互，延迟就增加几秒。对于实时性要求极高的场景，尽量合并 Sub-Agent，或者采用异步处理。
- 调试难度：多层架构下，定位问题链路的成本很高。必须配套完善的 Tracing 系统，记录每一层的输入输出和耗时。
Harness Engineering 的核心不在于堆砌技术名词，而在于承认 LLM 的不确定性，并通过工程手段将其收敛到业务可接受的范围内。
从 SPEC 到 Script，这是一个从开放到收敛的过程。初期可能觉得繁琐，但当你的系统开始承载真实业务流量时，你会发现这些看似冗余的围栏，才是系统稳定运行的唯一保障。真正的技术深度，往往体现在对边界的控制上，而非对能力的无限追求。
