别让个人提示词成为技术债:AI 时代的组织知识资产化路径

你是不是也见过这样的场景：业务专家花一晚上调出的完美Prompt，在他休假第二天就开始频繁报错——没人知道那段3000字的提示词里埋了三个从未触发过的条件分支，更没人敢改。

这不是Prompt写得不够好，而是个人经验正在被错当成组织资产。

当AI应用从Demo走向生产，我们才发现：Prompt工程从来不是软件工程。那些存在个人文档里的长提示词，本质上是一份没有版本控制、不可diff比对、离职即失效的”技术债”。

本文从Harness四层运行时谈起，提出交付体系的五层Agent协作架构——不是教你写出更好的Prompt，而是让Prompt从个人技艺进化为团队基础设施。

Harness 并非简单的工具集合，而是一种分层运行时架构，其设计目标在于界定 AI 系统与外部世界交互的边界与协议。该架构通过四层严格分离，将”智能”拆解为可观测、可控制、可复用的原子能力。

Agent 层构成系统的认知中枢，负责任务规划、上下文维护与记忆管理。其核心特征在于状态的持久化能力——通过显式的记忆操作接口，系统得以跨越会话边界维护长期知识图谱。然而，这一层被刻意设计为”无业务逻辑”的纯粹认知框架，不涉及任何特定领域的流程定义。

工具层构成了系统与外部数据世界交互的接口层。通过结构化数据源（datasource）、时效性信息检索（web_search）及计算环境（ipython）的封装，该层提供了确定性的原子操作能力。值得注意的是，工具层遵循”单轮约束”与”显式调用”原则，每个工具的执行都是独立、无状态、可验证的，这种设计确保了系统行为的可预测性。

合规层作为隐式治理机制，在数据流转的关键节点插入自动校验。这种设计体现了”防御性架构”的思想——风险管控不应依赖上层的自觉，而应固化在基础设施层，通过数据时效性验证、高风险内容拦截等机制，确保输出符合领域规范。

反馈层则定义了系统与用户的交互协议，不仅包括结果呈现，更涵盖错误码体系、状态报告与异常解释。这一层确保了即使在上层逻辑失效的情况下，系统仍能提供可理解的诊断信息。

Harness 四层架构的根本意义在于能力边界的清晰化：它提供了构建复杂系统的”乐高积木”，但刻意回避了”如何拼装”这一编排问题，从而为上层业务架构留下了创新空间。

在 Harness 原子能力之上，Skills 构成了工作流的过渡形态。这种过渡性体现在其采用自然语言作为编排媒介，通过提示词模板将 Harness 工具层的多轮调用打包为可复用单元。

Skills 的存在具有历史必然性。在业务需求快速变化、流程频繁调整的阶段，提示词驱动的工作流提供了低摩擦的迭代能力——修改一段描述远比重构代码更为敏捷。然而，这种灵活性以效率损耗为代价：提示词中必然包含大量条件分支与未触发逻辑，每次调用都需全量加载并消耗推理资源；同时，自然语言的模糊性导致版本控制与差异比对难以精确进行。

更为关键的局限在于，Skills 作为”静态文件”，无法建立动态演进机制。当某一流程被验证为高频且稳定时，提示词驱动的执行模式反而成为瓶颈，此时需要向代码工作流演进——通过 Python/JSON 等结构化语言定义状态机，将确定性逻辑从 LLM 推理中剥离，仅保留真正需要认知能力的环节。

Harness 与 Skills 的关系因此呈现为一种松散的层级耦合：Skills 依赖 Harness 提供的原子能力，但 Harness 不约束 Skills 的实现形式；这种设计允许 Skills 作为一种”可丢弃的中间层”存在，当业务逻辑成熟时可被更高效的代码实现替代，而无需改动 Harness 底层。

交付部门面临的本质挑战在于知识形态的转化：将分散在个体经验中的隐性知识，转化为可复用、可进化、可规模化的组织资产。基于 Harness 四层底座，需构建五层业务编排架构，实现从”个人提示词工程”到”系统化工作流”的跃迁。

主管 Agent 作为交互入口层，承担着意图识别与调度决策的职能。其核心价值在于屏蔽底层复杂性——交付人员无需知晓 Skills 的存在与否，只需通过自然语言描述业务需求。主管 Agent 基于 Harness Agent 层的推理能力，解析需求意图，决策调用路径，并建立会话状态的持续追踪。这一层实现了”对话即接口”的理念，将 Harness 的记忆管理能力转化为业务上下文维护能力。

需求 Agent 构成组织的知识感知层，采用 T+1 的复盘机制，对前一日所有交互记录进行模式挖掘。不同于实时介入的调度逻辑，该层通过 Harness 的记忆存储能力，积累历史交互数据，识别高频重复任务与共性痛点。这种设计体现了”数据驱动”与”实时响应”的解耦——实时层保证响应速度，复盘层保证知识沉淀。

Skills 管理 Agent 作为进化中枢，承担着工作流生命周期管理与工具需求治理的双重职能。一方面，它基于需求 Agent 的输出生成新的 Skills 模板，分析执行日志以压缩冗余提示词，并将确定性的 Skills 编译为代码工作流；另一方面，它监测 Skills 中”虚拟工具”（即已定义接口但尚未实现的工具占位符）的调用频次，当某一虚拟工具被引用达到阈值时，自动生成结构化的工具开发需求单，推送至产研工程师队列。

这种设计实现了”需求提出”与”工程实现”的分离：Agent 负责识别能力缺口与定义接口契约，而工具的实际开发、测试与部署由工程师完成，并注册至工具管理系统。这种分离显著降低了架构复杂度——Agent 层无需具备代码生成与系统部署的权限，仅通过标准化的需求单与工具注册表与工程团队协作。

Skills 执行 Agent 是 Harness 工具层的前置代理，在调用原子能力之前执行状态检查与依赖验证。通过查询工具管理系统中的状态标，该层能够识别虚拟工具并触发优雅降级：当检测到工具尚未上线时，不向用户返回错误，而是提供替代方案与上线预期。这种机制确保了交付承诺的可控性，同时通过状态反馈为 Skills 管理 Agent 的需求提报提供数据支撑。

工具层在 Harness 原生能力之上扩展团队自建工具，形成统一的资源池。所有工具由工程师开发并部署至工具管理系统，通过中心注册表同步状态，为上层的状态检查提供权威依据。

五层业务架构与 Harness 四层底座构成了垂直的分层解耦与水平的职责分离。

在垂直维度，业务层复用 Harness 的基础设施：主管 Agent 与需求 Agent 依赖 Harness Agent 层的记忆与推理；执行 Agent 与工具层依赖 Harness 工具层的原子能力；合规与反馈则完全复用 Harness 的底层实现。这种复用确保了业务创新不触及稳定的基础设施。

在水平维度，五层 Agent 之间形成了流水线式的协作关系：主管 Agent 负责”接入”，需求 Agent 负责”复盘”，管理 Agent 负责”进化”与”需求治理”，执行 Agent 负责”兑现”。

信息流自上而下（需求→调度→执行），知识流自下而上（执行日志→复盘分析→优化生成/工具需求），构成了闭环的学习系统。特别值得注意的是，工具开发作为关键的人工介入点，通过需求单机制融入了自动化流水线，既保持了 Agent 系统的自治性，又确保了工程实现的严谨性。

这种架构最终解决了交付领域的三对矛盾：标准化与灵活性的矛盾（通过 Skills 过渡与代码演进）；个人经验与组织资产的矛盾（通过需求 Agent 的挖掘与管理 Agent 的固化）；工具就绪与流程就绪的矛盾（通过虚拟工具、状态检查与工程师协作）。

Harness提供了舞台，五层Agent编排了剧目，而Skills的过渡与演进，以及 Agent与工程师的协作分工，则确保了剧目可以随业务成熟而不断精进，且基础设施始终处于可控的工程治理之下。