企业 Agent 的提示词，真正缺的不是技巧而是上下文

以下是一种常见但非特定企业的失败情境：同一套模型，演示时能快速总结合同、分析订单，到了真实工作中却不断遗漏前提。团队于是收集“万能提示词”，把一句要求扩写成几百字，结果输出更长了，责任却仍然模糊。问题不在措辞是否专业，而在于企业把本应由系统维护的业务上下文，临时推给了提问者。

本文的核心判断是：企业 Agent 的可靠性，主要取决于上下文是否可定位、可授权、可验证，而不是提示词是否华丽。好提示不是咒语，而是一份最小任务契约。它应让 Agent 知道在处理哪个业务对象、为什么处理、可以相信什么、必须遵守什么、能做到哪一步，以及谁来确认结果。

为什么一句“帮我分析”会在企业里失效

个人使用通用 AI 时，缺少背景通常只会得到笼统答案；企业场景里，缺少背景会沿着流程放大。以“判断这张订单是否需要升级处理”为例，订单号只是入口。可靠判断还依赖客户承诺、库存位置、供应商交期、合同罚则、例外政策、历史沟通和当前负责人。任何一项不明确，模型都可能给出语义流畅但业务上不可执行的建议。

这种失败通常由四条因果链形成。

第一，系统按部门建设，任务却跨对象发生。订单在 ERP，承诺在合同，沟通在 CRM，例外规则在文档中。用户知道它们有关联，但 Agent 只看见当前窗口。第二，同一个词在不同团队中含义不同。“高风险客户”可能指回款、续约、合规或交付风险；没有定义，模型只能猜测。第三，权限与动作没有一同描述。能读取价格不等于能修改报价，能建议延期也不等于能通知客户。第四，组织只评价答案“像不像”，没有定义证据、置信度和复核点，错误因而无法沉淀为规则。

因此，增加更多形容词不会修复结构性缺口。真正需要设计的是从问题到证据、从证据到判断、再从判断到动作的上下文链。

“任务上下文六面体”：把提示变成最小契约

可以用“任务上下文六面体”检查一次 Agent 任务。六个面都必须被显式处理，但不等于每个面都要填入复杂内容：低风险、纯只读且结果易核验的任务，可以在说明理由后把某一面标记为“不适用”。关键是主动判断，而不是默认忽略。成熟做法仍是由系统、知识库和工作流自动补足大部分内容。

对象面回答“正在处理什么”。它不是“销售数据”这种范围，而是某个客户、合同、设备事件、项目阶段或一组有明确口径的记录，并带有时间截点和版本。

目标面回答“哪个决定将因此改变”。例如不是“分析流失”，而是“决定本周由谁联系哪些即将续约的客户，并选择哪类干预”。目标越接近责任动作，输出越不容易停在常识。

证据面列出允许使用的系统、文档、字段与新鲜度，同时标记冲突时的优先来源。Agent 需要区分事实、推断和缺失信息，不能把检索到的每句话都当成同等可信。

规则面包含业务口径、例外条件、合规限制和计算约定。它还应说明哪些规则是强制约束，哪些只是经验建议，避免把过时惯例误当政策。

权限面定义可读、可建议、可提交审批和可自动执行的边界。企业 Agent 的能力不是一个开关，而是一组按对象、角色和风险分级的动作许可。

验收面规定输出格式、证据引用、置信说明、审批人和失败时的降级方式。它把“回答得不错”改造成“结论可以复核，动作可以撤回”。

例如，一个假设性的设备服务任务，不应只写“制定维修方案”。更完整的任务契约会指定故障事件、停机影响、可用技师与备件、服务等级承诺、不得绕过的安全规则，并要求输出三套可比较方案、所依证据、成本区间和需要调度主管批准的动作。这不是把提示写得更长，而是把决策结构写清楚。

用一场案例推演校准上下文

与其先建一个庞大的“提示词中心”，不如选取一次重复、高价值、可回看的真实任务，围绕它做完整推演。推演不是产品演示，而是让参与者在同一时间截点、同一证据条件下暴露各自默认的前提。

推演样本。 业务负责人冻结一份当时真实可见的任务材料，包括业务对象、制度版本、系统记录、人工沟通和最终动作，同时暂时隐藏结果。输出是一张任务边界图；检查点是不同岗位能否先对“正在决定什么、谁承担后果”达成一致。

角色互换。 流程负责人、领域专家、数据负责人和安全人员分别从六个面审查样本。某一面若不适用，必须写明风险理由；若适用，则指定来源、所有者和有效时间。输出是字段映射、规则优先级、动作许可与验收模板，而不是一段孤立提示。

双轨对照。 Agent 在不写入业务系统的条件下生成计划和建议，原责任人同时按既有流程判断。项目组比较证据遗漏、错误归因、人工覆盖和复核时间，并追问分歧来自数据、规则还是目标。通过标准不是两者答案完全一致，而是每个分歧能被定位。

动作演练。 对创建待办、预填表单或提交审批等低风险动作做沙盘测试，刻意加入来源过期、权限不足和系统中断。流程所有者确认业务结果，技术团队验证降级与回滚，治理角色检查审计记录。只有异常能被正确拦截和路由，动作才进入真实工作流。

运行回看。 规则变更、字段迁移、责任人调整和典型失败都应触发上下文包更新。团队持续观察来源过期率、人工补充次数、无证据结论、覆盖原因和从建议到处置的周期。维护的是任务契约，不是某一句曾经表现良好的提示。

常见失败并不发生在提示框里

最常见的误区是把六面体做成更大的静态模板。规则一旦变化，模板不会自动失效，反而让旧信息更像权威。每项上下文都应有所有者、版本和适用范围。

第二个误区是“给 Agent 看全部资料”。上下文越多不必然越准确；无关记录会稀释关键证据，权限也可能被不必要地扩大。应围绕当前对象逐层检索，并明确停止条件。

第三个误区是过度规定方法。对高风险计算可以指定口径，但对探索任务把每一步锁死，会压缩发现替代解释的空间。较好的做法是固定约束和验收，允许 Agent 提出计划，再由人确认执行路径。

第四个误区是把自然语言输出直接当动作。涉及付款、客户承诺、人员安排、合同修改或安全生产时，模型建议必须进入既有审批链，并保留原始证据与覆盖记录。无法追溯、不可撤回的自动化，不应因演示顺畅而进入生产。

最后，提示设计不能补救不存在的数据。如果关键事实没有记录、口径长期冲突、流程责任无人承担，Agent 只会更快暴露这些问题。此时正确产出可能是“信息不足，无法判断”，而不是强行给出答案。

什么时候提示已经够用

判断一份任务契约是否成熟，不看它有多长，而看三个业务事实：责任人能否据此复核结论，越权或缺证据时系统能否停下，处理结果能否反过来修正规则。三项仍有一项说不清，就应缩小任务范围；三项都成立，才值得增加动作权限。提示的终点不是一次漂亮回答，而是一项在异常条件下仍能被组织接住的工作。

在 Luminent 的方案诊断中，提示词会被当作任务契约的可见部分，优先检查知识来源、权限断点与验收责任，而不是先扩写措辞。只有这些上下文能随流程变化被维护，Agent 才具备扩大使用范围的基础。