常河你如果最近在看智能体（Agent）相关的开发，大概率绕不开两个词：一个是模型底座，另一个是“Harness”。我过去两个月一直在用 K2 模型搭配 Harness 框架做应用原型，过程中最大的感受是：模型本身再强，如果缺少一套规范化的过程方法，开发到后面基本就是靠感觉在堆配置。后来我把整套流程收敛成“基于角色分析”的过程方法，效果一下子清晰了很多。
这篇文章不是什么官方教程，而是我在实操中沉淀下来的一套打法。核心思路是：把业务需求先翻译成角色，再把角色翻译成 Harness 里的 rules、skills 和工具权限，最后让多个角色通过协作完成任务。它解决的是智能体开发里最常见的问题——需求很清楚，但落到配置上就乱套。适合正在做智能体应用、AI 自动化流程，或者想系统化梳理 Harness 配置的开发者参考。
1. 先搞清楚这套方法到底解决什么问题
1.1 “K2 + Harness”不是两个工具，是一套流程
先说术语。很多人第一次看到 Harness 会以为它是一个具体的软件，或者以为它就是 Agent 本身。实际上，Harness 是智能体的运行基座（Agent Harness），它负责加载模型、装配工具、管理上下文、执行循环、控制权限。Agent 是“谁在干活”的抽象，而 Harness 是“干活的现场”。
K2 在这里是模型底座。它给我的第一印象是长上下文能力和指令遵循做得相当稳，这对跑复杂业务规则非常重要。因为 Harness 里的 rules 和 skills 本质上都是文本指令，模型理解偏差一点，整个流程就歪了。把两者结合起来，你得到的是一套完整的生产链路：K2 负责理解与生成，Harness 负责装载和执行。
用一句话概括这套方法的价值：以前你在提示词里跟模型“说”你要什么角色，现在你把角色变成一个结构化的配置对象，通过 Harness 强制执行边界、赋予工具、串联协作。角色不是靠“演”出来的，而是靠“配置”出来的。
1.2 为什么传统提示词工程不够用
这个我必须多说两句。过去我做提示词工程，最常见的问题是：同样的描述，今天跑得好好的，明天就飘了。后来发现问题出在“角色扮演”太随意。你让模型扮演一个项目经理，它可能一会儿像客服，一会儿像行政，边界完全看当天的“心情”。
传统提示词的核心问题是：角色没有实体。它只是一段文字，没有一个可以被系统理解和约束的结构。而 Harness 这种框架天然支持把角色拆成多个配置文件——职责、权限、流程、技能各归各管。模型沿着这些文件跑，输出不稳定就追配置文件的问题，而不是反复改一长段提示词。
这也是“角色分析”这套过程方法存在的前提：你得把需求拆成角色，再把角色拆成可配置的单元。这一步做不好，后面用多少工具都白搭。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 角色分析的过程方法核心拆解
2.1 一句话理解“过程方法”
过程方法不是什么高深理论，它就是一句话：把“靠感觉”变成“按流程”。具体到 Harness 场景，我一般把过程拆成五个阶段：
- 业务场景梳理：明确这个智能体要解决什么问题，服务的对象是谁，输入和产出分别是什么。
- 角色画像设计：基于场景拆出需要的角色，比如项目经理、执行者、审查者、回复助手。
- 职责与权限边界：为每个角色划定职责范围，以及它可以使用哪些工具、不可以做哪些操作。
- 技能（skills）映射：把每个角色的关键能力固化成独立的技能文件，比如“写周报”“拆需求”“跑测试”。
- 规则（rules）编排：把流程性约束写进规则，比如“遇到高风险必须升级”