AI 模型在不断进步，此时一个有趣的现象正在显现：提示词正在慢慢变成企业“业务逻辑”的承载物，其中浓缩了领域方面的知识以及商业上的机密等。很明显，其关键的不同之处在于，提示词是为机器而不是为人类进行编写的。
事实上，越来越多的应用正将“业务逻辑”从传统代码转移至提示词中。头部 AI 产品的提示词已开始呈现出类似员工标准操作流程（SOP）或工作手册的样子，而不只是聊天机器人的指令。
你发现自己最近在编写提示词，这些提示词变得更长了，也更“野心勃勃”了，这正是我所指的那种趋势。
以 Anthropic 为 Claude 3.7 Sonnet 设计的系统提示词，它的情况是这样的：这个提示词既冗长又复杂，其中包含着诸多“该做”以及“不该做”的细节，从本质上来看，它就如同一份员工入职时需要用到的文档。随着推理模型不断地改进，提示词承担更多“核心工作”的这种趋势正在加快，而这主要是因为 AI 执行指令的能力已经快要达到人类的水平了。
因此，提示词正快速成为与 SOP 同等重要的企业资产，并且具有更大的杠杆效应。这些提示词能够嵌入 AI 智能体并全天运行。它们包含着敏感的内部流程、专有信息和关键的商业洞察，本质上是后大语言模型（LLM）时代的核心知识产权。同时比提示词的范围更宽泛，其本质就是整个 AI 的系统架构。
许多企业到目前为止还没有意识到这一转变，他们仍然把提示词当作比应用代码、数据和模型地位低的二等公民。
例如，大多数机构依然将 AI 项目当作传统数据科学或机器学习团队的项目。它们优先把时间花费在编写应用代码或者搭建基础设施工具上，而不是把精力放在打磨优质提示词上。在 AI 模型效率低下的时期，这些属于较为合理的“旧有习惯”。然而，如今这些东西正在迅速失去价值，对企业效率产生拖累并且增加了成本。
因此，本文将：
提示词正在“吞噬”业务逻辑
新型 AI 智能体框架和模型是热议的焦点，它们占据了 AI 话题的大部分头脑份额。然而，近期真正的突破在于 AI 模型理解用户意图与遵循指令的能力。
这种增强的指令遵循能力，使得复杂定制化解决方案的性价比大幅降低。过去，这些方案是为弥补早期模型缺陷而设计的，属于权宜之计。
一个贴切的类比如下：雇佣未受过教育的人时，你得把每个概念都分解成小块，然后给他们分配简单任务，不然就会把他们压垮；而雇佣拥有博士学历的人时，你只需给他们一本手册，然后说“去学吧”就可以了。
同理，更优秀的 AI 模型降低了让事情行得通所需要的大量定制化工作。随着 AI 智能体大量增加，能够预见企业应用的代码库规模会变小，因为业务逻辑正在加快围绕新的三位一体（提示词、模型、数据）而不是代码进行整合。
这意味着 AI 智能体架构正在趋向简化。你无需再编写复杂的对话树，也无需编写“智能体军团”来明确声明响应规则。
2025 年 3 月时，你能够用一个文件写出一个 AI 智能体，此智能体参考了 OpenAI 智能体 SDK 中稍作修改的座位预订示例。如今，创建一个合格的客服机器人或许只需不足 200 行代码，并且大部分“业务逻辑”本质上就是提示词。
f"""
# System context
你属于一个名为 Agents SDK 的多智能体系统。
...
# Your role
# Routine
请求他们的确认号码。
....
10.
# SOP
以下是给你的相关协议。
...
值得注意的是，这类提示词能够被任何人使用 Google 文档、Word、Notion 等工具来编写。它一般包含以下这些模块：
开发者实际需要编写的代码除了提示词外，通常不足 200 行，有的甚至少至 7 行，如下例所示：
seat_booking_agent 是在航空公司代理环境下的代理。它具备处理座位预订相关事务的能力，能够与航空公司系统进行交互，获取座位信息、进行预订操作等，以满足乘客的座位预订需求。
instructions=prompt,
tools=[update_seat],
所以，只要写好提示词，就能完成智能体 20%到 50%的开发工作，其具体比例取决于场景。提示词的权重和用例的复杂度以及智能体的类型有着直接的关联。对于生化研究智能体这类复杂垂直领域的应用来说，定制模型和数据集的重要性会明显提高。
核心结论是：
成功驾驭新范式需要有强大的架构设计，也需要进行系统性思考，不能仅仅依靠传统的软件工程能力，因为传统的软件工程能力正在加速商品化。率先认知到这一转变并且能够适应这一转变的企业，将会获得持久的竞争优势。
2025 年的多数企业在运作 AI 计划时仍采用传统数据科学项目模式，这是令人遗憾的，并且它们为此付出了高昂的代价。
企业构建AI智能体的常见误区
许多企业由于惯性，错误地把提示词当作只是纯技术团队的职责。这种认知有着根本性的错误，那就是数据科学或者技术团队不应该独自承担 AI 智能体/自动化项目的成败责任。
这种误解催生了糟糕的工程实践。例如，把提示词直接嵌入到代码库中，这样做存在安全风险，还会制造冗余审查。把提示词禁锢在代码库内，会使本应主导其优化的关键业务决策者与之疏离。
假设把前文提到的客服提示词直接写到后端代码里：每当有政策或者话术进行更新的时候，都需要开发人员去修改代码并且重新进行部署。这种方式极大地拖慢了业务的敏捷性，还让技术团队承担了本不该有的负担。
事实上，开发者不是核心利益方，而是客服业务总经理。总经理应当和开发者一起对提示词承担责任。
把提示词简单地当作应用代码来管理，实际上是把它当作“二等公民”。大多数人依然把它看作是 AI 应用的附属部分，而不是需要单独进行管理的核心财物。
这种做法不仅过时低效，更存在安全隐患：
提示词是企业商业知识的结晶，所以总经理和业务主管等应当深度参与其设计，因为 AI 智能体放大的是他们的业务价值。然而，当前多数 AI 项目组与业务专家的协作存在严重不足。
企业应通过技术/业务方均可访问的独立平台来管理提示词。
问题的根源是工具与文化。现在已经有 Langsmith、Braintrust 等专业提示词管理工具了，然而这些工具大多是面向开发者进行设计的，业务决策者往往不被当作主要用户。
市场迫切需要能够促进跨团队之间实现无缝协作的工具。Databricks虽然在其数据血缘产品里引入了业务方的协作功能，然而这远远没有达到实际的需求。
这些只是新兴反模式当中很小的一部分。随着 LLM 越来越“智能体化”，那些不重视提示词核心地位的企业将会遭受很大的损失。
提示词的价值分层：如何分配资源
避免误解的是，并非所有提示词都具有同等重要性，就如同并非所有业务流程都属于关键范畴一样。
优先优化哪些提示词？需明确其商业价值因场景而异：
尽早识别出高价值的提示词，投入顶尖的人才并配备最强的安防措施，对其结果表现进行严格追踪。这些提示词将成为值得全力去守护并且持续进行优化的核心竞争壁垒。
最佳实践建议
理解提示词成为新的竞争壁垒只是迈出了第一步。那么，如何围绕提示词来构建强大的智能体 AI 产品呢？企业至少需要采取以下这些措施：
A) 严格追踪与A/B测试
在测试环境以及生产环境当中对提示词开展 A/B 测试。随着 AI 智能体肩负起“更多的职责”，性能监控变得越来越关键。就如同员工需要进行绩效评估一样，智能体（还有提示词）也需要持续地接受审查和优化。
当下企业愿意对社交媒体互动进行仔细追踪，然而却忽视了对提示词的性能进行监控。这种状况需要改变，必须要用科学的方法来量化提示词对系统输出所产生的影响。
可以选用 promptLayer、promptFoo、Langfuse、LangSmith 等工具，也可以选用任意的 LLMOps 方案。这些工具的功能较为相似，在进行选择的时候，只需要考虑部署的方式，比如开源或者托管等，并且主流的云厂商也提供类似的工具。
B) 强化安全管控
关键提示词需要实施严格的访问控制，因为它具有敏感性，所以建议将其存储在服务端。多数企业误以为将其存入代码库就安全了，这看似是常识，但实际上是大错特错的。
C) 业务方深度参与
业务决策者直接参与提示词的设计与迭代。随着 AI 智能体的认知能力逐渐趋近人类，应该由领域专家来承担优化的责任，而不是由缺乏专业知识的开发团队或产品经理来承担。
不要依赖非领域的专家，像产品经理或者开发者来完善提示词。特别是当 AI 智能体拥有人类级别的认知时，业务方面必须参与到审核工作中。
D) 实施评估驱动开发（EDD）
评估驱动开发（EDD）是个宏大课题，但其核心可概括如下：
在开发 AI 智能体之前，需要预先明确什么是“好结果”，什么是“坏结果”。这些被称作基准（或者测试用例）的东西，将会成为后续所有智能体进行修改时的对比标准，以此来衡量优化的方向是否正确。像这样的基准测试，也被称为“评估基准”（evals）。
建立评估基准之后，要持续对提示词进行迭代。一直迭代到提示词的表现超越基准并达到满意的水平，这里的标准可以基于人类的直觉判断或者大语言模型的评估。为了防止钻成功标准的空子，需要事先和业务决策者明确“成功”的具体含义。
译者：boxi。
