从提示词到控制框架：企业级AI Agent的工程化演进之路

在企业级AI应用场景中，大语言模型虽然具备强大的推理能力，但其固有的结构性约束使得直接将通用模型投入生产环境面临巨大挑战。当我们将AI Agent应用于复杂业务场景时，如何让这个“高性能CPU”具备内存管理、进程调度和文件系统等操作系统级别的能力，成为工程落地的核心命题。

大模型的四大结构性约束

本文基于构建企业级AI Agent平台的完整实践，系统梳理了从Prompt工程到Harness工程的技术演进路径。核心演进逻辑是：每一层工程化的出现都是因为前一层次遇到了天花板。

Prompt工程阶段的局限与突破

理解大语言模型的结构性约束是所有工程努力的前提。与模型规模或训练数据无关，这些约束是Transformer架构的固有特性。第一，上下文窗口是稀缺资源——128K的上下文容量看似充裕，但在多步骤Agent执行中，工具调用的返回结果可能迅速膨胀至200K以上。第二，注意力稀释效应导致“LLM越跑越蠢”——当上下文膨胀到100K时，70%的内容可能是工具返回的原始JSON，只有10%是当前步骤真正需要的指令。第三，数据搬运谬误造成信息损耗——模型在跨步骤传递数据时，可能截断长字符串、遗漏嵌套字段，甚至“忘记”关键ID值。第四，无状态缺陷使得跨执行的学习成为空谈——每次对话对模型来说都是“第一次见面”，历史经验无法积累。这四个约束共同指向一个结论：原始大模型只是一块高性能CPU，要让它稳定执行企业级任务，必须在它外围构建操作系统级别的基础设施。

Context工程：四层防线的分层防御策略

早期的工程化尝试始于Prompt工程——将所有信息塞入System Prompt，通过结构化文档（如CLAUDE.md）最大化上下文利用效率。然而，这种方式的局限性很快显现：500+行的静态文档占据了大量宝贵的上下文空间，指令遵从率在多步骤链路中急剧下降。更关键的是，工程师们开始意识到一个根本性问题：通过Prompt层面的技巧（如强调标记、重复注入）试图让模型“记住”规则，本质上是在和模型的注意力机制进行一场“军备竞赛”。当上下文从10K膨胀到100K时，一个标记获得的注意力权重被稀释了10倍——你加三个标记，上下文膨胀又稀释了它们，这是一场永远赢不了的游戏。真正的出路不在Prompt层面，而在系统层面：与其让模型“记住”规则，不如让系统“强制执行”规则。

三层记忆架构与单一表示原则

Context工程阶段的核心判断是：上下文管理是一个需要分层防御的系统工程。单一压缩策略无法应对不同粒度的数据膨胀需求。我们构建了四层上下文防线，严格按照数据膨胀发生的时间顺序逐层拦截。L1层（工具结果压缩）采用“大结果外置+引用替换”机制，当单次API调用返回超过8000字符或数组超过10个元素时，自动将完整数据存入数据库，上下文仅保留引用指针和摘要。这从根本上消除了模型“优化”大数组的机会——它只能通过显式调用获取完整数据。L2层（语义压缩）使用小模型对中等规模数据进行“注意力蒸馏”，将50KB的原始数据压缩为2KB的高密度结论。L3层（对话压缩）在上下文使用率超过85%时启动，将整段对话压缩为结构化交接文档而非简单摘要。L4层（数据总线）基于步骤定义的声明式依赖分析，按需预取被压缩的历史数据，类似于CPU缓存的prefetch策略。

如有侵权，请联系删除。