垂直和领域 Agent 的护城河：上下文工程

作者：望宸

技术术语的更迭，不仅是语言表达的更替，更代表着思维范式的转变。上下文工程这一新术语，之所以能引起业内共鸣，折射的是智能体复杂性的演化和应对策略的转变，是对现实中算法和工程挑战的一种集体回应，尤其是垂直和领域智能体。

图源：宝玉@X

现有的大模型已经非常智能。但即便是最聪明的人，如果不清楚自己要做的事情的上下文，也很难给出令人满意的交付。两款产品可能在做完全相同的事情，一款给人感觉充满魔力，但另一款却像个廉价的演示品。差别在哪里？就在于上下文工程的构建上。

01 从一个场景开始，感受上下文工程的魔力

场景设定：你是某款智能体的产品经理，正在钉钉上收到研发发来的私信：“有个问题想确认一下，新版的导入功能是不是只支持 CSV？我们这边需要开始写接口了。”

一个普通的智能助手可能会直接帮你草拟一句回复：“是的，目前只支持 CSV，后续可能会扩展。”表面上看没错，但没有考虑到项目当前阶段、上下游依赖、语气风格、团队共识等细节，容易引起误解或返工。

而一个具备“上下文感知”的智能体，会先主动检索：

• 项目状态：按照项目规划，导入功能这周进入开发阶段。

• 需求文档：设计稿明确列出 V1 支持 CSV 和 JSON，但后者会延后一周上线。

• 团队氛围：研发那边人手吃紧，担心 scope 变化影响进度。

• 任务历史：曾有一次因需求细节未澄清导致返工，刚复盘过。

• 个性化语气设定：直接、细节清楚、减少异步往返。

最终生成的消息可能是：“目前计划 V1 支持 CSV 和 JSON，但 JSON 要到下周才能接接口。你这边这两天先按 CSV 做没问题，接口格式我一会儿就在需求列表上进行补充。”

魔力在哪？

它不是因为模型算法更好，而是因为它理解了：

• 当前的任务规划

• 团队过往的沟通隐患

• 对方的工作状态与担忧

• 文档/知识库的实时状态

这正是“上下文工程”的魔力所在，用足够有结构的信息输入，换来更自然、更可控、更满意的输出行为。这种上下文工程的设计才会让智能体更像一个人去思考任务。

02 提示词->提示词工程->上下文工程的演进

提示词，是擅于利用大模型的用户手上的魔力笔。

通过具象的提示词可以获得尽可能满意的输出。我们在教大模型理解我们的同时，也在学习如何被理解。每个提示词都是一面镜子，映照出我们对“理解”本身的理解。比如提示词大师李继刚提供过大量、高质量的提示词。来看个例子：

这种用结构化的提示词挖掘大模型能力的体验，早期造就了大量围绕提示词调优的 Prompt Hacker 群体，也使得写提示词在一段时间里，成为优化大模型输出的核心技巧。然而，这种做法的核心问题也很快暴露出来：过度依赖个体经验，缺乏系统性、稳定性和可复用性，同一个提示词在不同模型或不同时间段下的表现千差万别，一套提示词很难横跨多个任务、多个上下文等等。

由此延伸出了提示词工程，Agent Builder 们试图将对大模型的调试经验固化为规则，将试错过程转化为一套可维护、可迭代的编排流程，打造相比通用大模型在某个场景下更具竞争力的行业智能体。例如，在实际项目中，你会看到团队构建了一组系统提