生产环境不相信 Prompt：企业 Agent 的五层工程责任
把业务规矩写进 System Prompt 不等于工程治理。Prompt 只是给模型的建议性输入，承载不了生产环境需要的确定性保证。本文深度拆解企业 Agent 在复杂调用链下的七大生产故障形态，揭示为何提示词工程无法解决执行失控，并给出五层各自要守的边界，以及哪几层企业必须自己掌握。
导读：在企业级 AI Agent 的工程落地中，许多团队最初的直觉往往是把一切治理期望都寄托在提示词（Prompt）上——在 System Prompt 里洋洋洒洒写满几十条行为红线、安全准则与操作禁令。然而当系统一旦接入真实的生产环境，面对跨系统工具调用、长时间运行的多阶段任务以及多 Agent 协同交互时，这些写在自然语言里的规则便会频繁失效。
Prompt 能告诉模型「该怎么做」，但承载不了生产环境需要的「保证」。 企业业务系统对稳定性的诉求，从来不能建立在概率采样与自然语言理解的良好愿望之上。生产可靠性来自 Prompt 之外的四层——上下文、循环、图、Harness——各自守住自己的边界。
按照企业数字劳动力基础设施的通用定义，Harness 即「模型之外的那一层——Agent 担任什么角色、要守哪些企业制度、能用哪些知识」。关于角色、制度与知识怎么在上岗前装进工作区，可参见专题 Harness 工程；本文重点探讨的是当 Agent 真正进入运行时、开始自主发起系统调用与协同作业后，外面那几层各自要守住什么边界。需要特别明确的是：HarnessServer 是这一层中负责上下文精准组装与分发的专用组件，它与上下游协同支撑起整体工程，而非 Harness 的全部。
一、承认局部价值：提示词在工程中的真实定位
探讨 Prompt 的局限性，绝不意味着否定提示词本身的工程价值。相反，在成熟的软件分层中，高质量的提示词依然是 Agent 具备生产可用性的必要前置条件。
在清晰的工程分层下，Prompt 承担着明确且不可替代的职责：
- 角色与人设立标：明确当前 Agent 的业务职责范围、思考立场、语言风格以及协作定位。
- 结构化输出契约：向模型提供严格的模式定义（JSON Schema）、类型化工具调用参数契约以及期望的返回数据形态。
- 领域任务指令与少样本范例（Few-Shot Examples）：通过具有代表性的输入输出样例，引导模型在特定业务领域（如合同审查要点提取、运维日志根因归纳）中建立合理的推理步长。
- 统一配置文件规范化：优秀的主配置文件本身就是系统指引的重要制品。例如，在标准化工程实践中，上下文供给组件 HarnessServer 会根据 Agent 的类别与骨架定义，自动面向主流框架生成标准化的
CLAUDE.md、AGENTS.md、NODAL.md等上下文文件。在这些文件中，通用规则与公共段落保持字节级别的稳定性，不仅使模型能够准确获取环境指引，还能高效复用模型厂商的提示词缓存（Prompt Cache）机制以降低推理开销。
此前我们在探讨 生产级 Skill 资产治理 时曾详细阐述过，单靠编写一篇充满自由发挥的「流水账」无法构建出高可用的生产技能，Skill 必须经历静态扫描、格式校验与版本晋级。然而，即使我们拥有了经过充分调试的高质量提示词与标准化的 Skill 资产，当 Agent 真正开始运转、调用外部世界接口时，新的挑战依然会扑面而来：
提示词写得再精妙，它依然只是输入给大模型的文本 Token，而不是操作系统的执行锁。
把企业的业务制度硬编码在提示词作文里，试图以此解决运行时的越权、死锁、资金消耗与数据泄漏，是企业 Agent 落地过程中最普遍、代价也最惨痛的认知误区。
二、撕开全局伪命题：把制度写进 Prompt 不等于工程治理
为什么说「把规矩写进 System Prompt 就等于治理」是一个不成立的伪命题？
根本原因在于：自然语言的建议性输入与确定性的执行约束之间，存在不可弥合的工程不对称性。
1. 输入与门禁的范式错位
在传统的企业软件工程中，任何安全与业务限制都是通过代码逻辑、访问控制列表（ACL）和数据库事务强制实施的。一个普通用户无法删除生产数据库，是因为底层权限系统剥夺了其对应的执行凭据，而不是因为在网页登录框上方写了一行文字「请您不要删除数据库」。
而在许多初级 Agent 架构中，系统通过向模型提供高权限的工具接口（例如具有写权限的数据库执行器、能够发送公网 HTTP 请求的客户端），然后寄希望于在 System Prompt 里追加一句：「警告：除非用户明确要求，否则绝对严禁执行任何删除或写操作」。
这种做法混淆了「意图表达」与「执行拦截」：
- Prompt 是 Advisory（建议性的）：它是模型的输入，模型输出的是概率最高的下一个 token，而不是确定的物理约束。
- 治理是 Enforcement（强制性的）：它必须具备布尔级别的真假判定，并在条件不满足时在操作系统或网络层拒绝执行，无论上层逻辑如何辩解。
2. 长链条执行下的必然退化
即使在单轮测试中，模型能够百分之百遵循提示词的要求，一旦进入真实的生产业务流，提示词的约束力便会呈指数级衰减：
- 注意力稀释（Attention Dilution）：随着任务的推进，工具返回的冗长 JSON 报文、环境错误堆栈以及用户的新指令不断涌入上下文窗口。最早置于 System Prompt 中的禁令在海量文本冲刷下，权重不可避免地被稀释。
- 指令漂移与目标冲突：当任务目标（「必须尽快恢复业务网络」）与安全限制（「不可重启关键节点」）发生内在冲突时，模型往往会在概率推演中优先选择达成主任务目标，从而自主推导并越过负向禁令。
- 对抗性与间接注入（Indirect Prompt Injection）：Agent 在调用外部工具读取用户邮件、抓取网页或解析供应商 PDF 时，外部数据中夹带的非结构化自然语言可能会欺骗模型，让其误以为这是来自系统的最新指令，从而覆写原有的提示词设定。
企业在生产环境中要交付的是具有严肃商业与法律责任的业务结果。依赖提示词的概率自律，无异于在毫无护栏的悬崖边缘任由自动驾驶车辆自由滑行。
三、分层范式：Prompt 只是五个作用域中最里面的那个
要彻底厘清提示词的局限，必须将 Agent 系统的工程架构做清晰的作用域切分。
正如技术专家 Shuva Jyoti Kar 发表在 Medium Google Cloud 出版物上的架构文章《From Prompt to Production: How Prompt, Context, Loop, Graph, and Harness Engineering Fit Together》（作者声明观点属个人）所指出的，现代自主系统不是单一维度的 Prompt 调优，而是由内向外嵌套的五个独立工程作用域：
| 层级 | 管辖的单位 | 核心职责 | 它管不了的边界 |
|---|---|---|---|
| Prompt 工程 | 一次调用 | 把单次决策定义清楚：角色、证据纪律、决策策略、类型化输出契约、弃权条件 | 结论是否为真；证据是否完整进入了上下文窗口 |
| Context 工程 | 一次调用的证据 | 把系统状态压缩为任务相关的证据包，保留事件时间、来源身份、授权范围与脱敏，区分「无信号」与「健康状态」，附带版本清单（Manifest） | 多轮任务推进；外部系统写入副作用 |
| Loop 工程 | 一次任务的推进 | 依据新观测更新当前信念 → 选择下一步动作 → 量化执行进展 → 评估预算与终止条件（verified / insufficient evidence / blocked / exhausted） |
多分支并行协调；组织审批关卡 |
| Graph 工程 | 分支、汇合与审批 | 把业务工作流表达为版本化的代码程序：显式划分确定性代码节点、模型推理节点与人工审批节点；边是类型化契约；模型无法擅自越过审批 | 节点崩溃恢复；并发资源锁；运行凭证隔离 |
| Harness 工程 | 运行时环境 | 把执行过程转化为可持久、可治理的可靠系统：持有持久状态、并发控制、幂等动作、执行时策略评估、沙箱隔离、可观测与审计留痕 | 无法修补更窄内层的逻辑缺陷 |
理解这五个嵌套作用域，有三条至关重要的架构铁律：
- 五层是同一个系统的五个作用域，而不是技术潮流或成熟度阶梯：一个简单的文本分类工具可能只需要 Prompt 和 Context 两层；但一个真正具备工具调用、多阶段协作或能够对外部生产环境造成副作用的企业级 Agent，必须完整具备外层的安全围栏。
- 外层修补不了内层的缺陷：Harness 可以高可靠地重试一个糟糕的 Prompt，但那只是高可靠地重复一次糟糕的决策；完美的 Prompt 推理不出被 Context 层遗漏的配置差异；再严密的 Loop 循环也不能让一次未授权的高危生产变更变得安全。
- 失败的共同形态，是把责任放错了层级：在工程现场，几乎所有的失控事故都可以归结为层级错配——用更强硬的指令去弥补 Context 缺失的证据、用更冗长的 System Prompt 去控制 Loop 失控的死循环、用自然语言在 Prompt 里表达系统授权、或者试图从非结构化的对话历史中去恢复崩溃的持久任务。
四、深水区踩坑：生产环境中的七大真实故障形态
将上述五个作用域映射到真实的生产挑战中，我们会发现以下七类典型故障形态，本质上全是因为把原本属于外层的安全责任，错误地丢给了最内层的 Prompt。
故障形态一：Prompt 里声明了「严禁删除数据」，模型在复杂调用链中依然执行了删除
- 归属层级：Harness · 执行时策略
- 典型形态：Agent 承担复杂的运维排错或大批量业务数据迁移任务。在执行了多轮工具调用后，中间件返回非预期的格式错误，模型自主推演认为环境残留导致冲突，为了达成最终交付目标，主动拼装参数调用了包含物理删除指令的清理工具。
- 为什么 Prompt 解决不了（责任放错层）：「用自然语言表达授权与禁令」是典型的层级错配。自然语言无法充当系统调用的拦截网；在多步推理与连续报错中，注意力稀释与目标对齐偏差极易诱导模型输出删除指令。授权策略必须在动作真正执行的那一刻，由外部 Harness 强制裁决。
- 产品里真实对应的机制： 在 ReadyForAI 架构体系中，拦截此类危险调用的真实底座是 OwlAudit 与 NodalOS 共同构筑的同步策略评估点：
- 机制的技术边界： 必须严谨指出：OwlAudit 的通用日志接入通道（General Ingest）只负责记录账本，不拦截已经发生的系统调用；未在 NodalOS 中显式挂接 Hook 的私有调用路径不走本评估；同时，NodalOS 底层的 Worker 操作审批原语默认处于关闭状态。因此，工程上不能将其夸大为「自动拦截每一次危险调用」，必须在控制面中明确配置挂接策略。
故障形态二：长任务执行到中途，因容器重启或网络超时导致状态全丢
- 归属层级：Harness · 持久状态
- 典型形态：耗时数小时的复杂流水线任务执行到关键阶段，底层的计算容器遭遇宿主机轮转重启，或是由于上游 API 瞬时超时导致连接断开。当外部调度器重新拉起实例时，内存中的执行进度全部消散，长链条只能推倒重来。
- 为什么 Prompt 解决不了（责任放错层）：「试图从对话历史中恢复崩溃的任务」是典型的层级错配。正如 Shuva Jyoti Kar 所指出的：「上下文是模型看到的，状态是系统知道的」（"Context is what the model sees; state is what the system knows."）。上下文窗口仅仅是一次性工作记忆；任务的持久状态、前置依赖与执行时间线必须外置于会话窗口之外。
- 产品里真实对应的机制：
解决状态易失的核心原则是状态外置。任务控制面 PathPilot 将业务任务的生命周期、多阶段流水线、决策节点以及前置依赖关系完全持久化在运行容器之外：
- 外部时间线与阻塞记录：任务的阻塞、等待、升级等状态均由 PathPilot 持久化存储。
- Agent 自报进度：在任务执行过程中，Agent 可调用可选 MCP 工具
report_progress，按照规范的progress_type与执行摘要，主动向 PathPilot 任务时间线写入进度记录，使外部控制台与协作链路能够随时读取阶段性交付。 - 架构铁律：整个控制面遵循「本仓只存状态，由外部执行器推进」的工程约束。
- 机制的技术边界： 我们必须向工程团队诚实厘清系统能够恢复什么、不能承诺什么：系统恢复的是调度台账、任务状态与在时限内可续接的会话，而不承诺自动换 Worker 与自动重试。 在 NodalOS 侧，Coordinator 调度台账写入周期快照、崩溃重启后通过收件箱重放与 WAL 交叉恢复，进程按策略重新拉起，Worker 会话在归属校验与时限内可通过厂商 transcript 句柄续接；在 PathPilot 侧，任务状态、阶段与时间线全部外置于数据库，崩溃后由后台定时对账收敛，并区分可重试的瞬时失败与需升级的业务失败。但系统不承诺自动换 Worker 接力或自动重试引擎——Worker 换人仍须走人工 reassign 或 handoff 路径，阶段重试亦仅限重跑本阶段。
故障形态三：两个 Agent 互相驳回陷入无限死循环，Token 与下游 API 成本瞬间失控
- 归属层级：Loop · 预算与终止
- 典型形态：在编排型多 Agent 协作场景中（如生成 Agent 与评审 Agent），双方对某个实现细节理解分歧，一方不断提出修改意见，另一方反复提交无法满足要求的微调版本，形成恶性调用循环，消耗海量 Token 并导致下游 API 账单骤增。
- 为什么 Prompt 解决不了（责任放错层）：「用更长的 System Prompt 去控失控的循环」是典型的层级错配。在 Prompt 中写「三次未解决则停止」在复杂的反驳交互中毫无效果，具体的争议内容会迅速淹没早期的停止指令。任务终止条件与预算上限必须由外部 Loop 控制层强制执行。
- 产品里真实对应的机制：
对失控死循环的治理必须依托多层次的预算状态机与外部遥测告警：
- PathPilot 预算四档状态机：PathPilot 严格跟踪任务消耗，将预算状态规范为四大真实档位：
normal（正常）、warning（预警）、degraded（降级）、exhausted（耗尽）。 - 超额覆盖请求（Override Request）：当任务预算耗尽触达
exhausted状态时，执行链条挂起并触发形式化的覆盖请求，必须由人工操作员或 OwlAudit 策略回写审批单号后，方可继续获取后续额度。 - 资源并发锁：PathPilot 提供资源锁机制，防止多个任务或并发 Agent 对同一外部资源产生死锁与重复消耗。
- HeronSentry 异常告警：只读观测面 HeronSentry 实时监测成本突增与同工具高频调用，一旦检测到异常调用频率，立即通过配置的 Webhook 向外部监控群组推送告警。
- PathPilot 预算四档状态机：PathPilot 严格跟踪任务消耗，将预算状态规范为四大真实档位：
- 机制的技术边界： 必须认清防线的性质：系统不提供物理停机熔断器，不向企业做出绝对杜绝一切消耗的承诺；HeronSentry 恪守只读观测与告警的定位，不主动执行网络阻断或任务关闭动作。
故障形态四：企业内部敏感数据被当作上下文，作为参数塞进了外部公网工具
- 归属层级：Context · 授权与脱敏 + Harness · 隔离
- 典型形态：Agent 在排查业务问题时读取了企业内网未脱敏的数据，在下一步需要使用公网搜索或第三方接口查询报错时，模型在组织检索关键词的过程中，将刚才读到的机密字段直接拼装到了公网请求的参数中。
- 为什么 Prompt 解决不了（责任放错层）：在 Prompt 中叮嘱「不要对外泄露机密」属于在最内层承担 Context 与 Harness 层的安全职责。当外部工具描述要求「提供尽可能详细的报错上下文」时，模型为了提高任务命中质量，极易将内网数据打包外发。
- 产品里真实对应的机制：
对抗数据泄漏最有效的工程原则不是事后过滤，而是预先收敛可见性边界：
- HarnessServer 角色可见性分发：HarnessServer 根据 Agent 的角色级别（Coordinator 编排者与 Worker 执行者）、Agent 类别与已购产品范围，精准下发可见的 Skill、SOP 与规则集合，执行层 Worker 默认无法直接看到超出其工作区定义的敏感配置。
- 双时态管理型记忆权限控制：HarnessServer 的管理型记忆功能默认处于关闭状态，且仅对被显式赋予
memory_access权限的 Agent 开放查询，未授权的 Worker 查不到。 - LarkScout 知识接口 mTLS 隔离：知识平台 LarkScout 的官方知识 MCP 接口默认保持关闭，仅允许受控 Agent 在启用 mTLS 双向证书鉴权通道的前提下接入检索。
- 机制的技术边界： 企业必须认识到：ReadyForAI 套件各产品没有内置数据防泄漏（DLP）扫描器，也不在运行时对工具入参进行实时的正则表达式敏感词扫描。系统的防护逻辑完全建立在预先收敛思想之上：在数据进入 Agent 视野之前，先把不该看的内容从可见集合中剥离。
故障形态五：为求绝对安全将所有动作设为人审，审批人面对海量弹窗最终闭眼全过
- 归属层级：Graph · 审批边界
- 典型形态：开发团队对 Agent 调用的所有外部工具一律开启强行弹窗确认。随着调用量攀升，审批人每天面临数百次低风险提示，严重的审批疲劳导致人类麻木地点击「全部批准」，致命操作在盲审中被直接放行。
- 为什么 Prompt 解决不了（责任放错层）：审批逻辑属于 Graph 层的节点类型化编排，提示词无法度量动态的组织负荷。在 Prompt 里要求「仅在极其危险时才弹窗」不仅缺乏客观定量标准，更将合规判定权交还给了模型本身。
- 产品里真实对应的机制：
解决审批疲劳必须依赖精细化的三档介入策略与工单聚合体系：
- OwlAudit 三档介入机制：OwlAudit 明确定义了三类介入模式，并由策略的
action_type字段精准选定：- HOOL（Human-out-of-the-Loop）：低风险或标准操作，无匹配规则时缺省放行自主执行，记录 Hash Chain 审计；
- HOTL（Human-on-the-Loop）：中等风险操作，自动执行，可事后干预，记入审计链；
- HITL（Human-in-the-Loop）：高危或超限动作，在执行挂接点上同步挂起，开辟人审工单。
- 工单生命周期管理：HITL 工单内置等待队列、升级链机制、超时兜底策略以及决策全程留痕。
- HITL 审批否决率追踪：OwlAudit 统计并向企业绩效主线贡献「HITL 审批否决率」指标，反映人审驳回的频度。
- AULO 统一待办 Inbox：人机协同中枢 AULO 通过统一待办 Inbox 集中汇聚来自各处的升级任务、未分配 Agent、议事待决以及 OwlAudit HITL 工单，操作员在一个界面中进行集中批示并回写上游系统。
- OwlAudit 三档介入机制：OwlAudit 明确定义了三类介入模式，并由策略的
- 机制的技术边界： 需要厘清的分工边界是：AULO 不内置任何审批引擎，它仅负责审批界面的聚合展示与操作转发；OwlAudit 的「HITL 审批否决率」反映的是人审被驳回的频度，它不是综合质量分，也不是合规打分；此外，系统中不存在所谓「秒级无阅读通过率」等未经工程验证的花哨指标。
故障形态六：更换底层模型或前端框架，Tool Call 格式与潜规则巨变导致全链路瘫痪
- 归属层级：Prompt · 输出契约 + 制品独立版本化
- 典型形态：企业从一家模型提供商切换到另一家模型提供商，或者将开发框架由一套开源实现迁移至另一套标准。原先针对特定模型精心微调的工具入参格式、特殊标记与隐式假设全部失效，调用频繁报错。
- 为什么 Prompt 解决不了（责任放错层）：Prompt 中的指令微调与具体模型的偏好强耦合。升级模型不能改变权限，模型更替不应破坏系统的执行契约，各层制品应独立版本化。
- 产品里真实对应的机制：
解耦模型差异需要标准化上下文文件与运行时协议适配层：
- HarnessServer 框架文件自动生成：HarnessServer 具备针对不同框架自动生成
CLAUDE.md、AGENTS.md、NODAL.md的能力，并确保公共定义段落保持字节级稳定，屏蔽具体框架差异。 - NodalOS 协议适配与异构纳管：底层基础设施 NodalOS 提供统一的协议适配层（A2A / ACP / MCP），在统一抽象下纳管 5 类 RuntimeClass（Native / Vendor / Sidecar / Basic / Coordinator）。
- HeronSentry 工具拒绝率观测：HeronSentry 在调用链中对工具拒绝率、首字延迟（TTFT）与输出截断率进行持续聚合分析，为架构团队评估新模型在执行层的兼容性提供客观指标依据。
- HarnessServer 框架文件自动生成：HarnessServer 具备针对不同框架自动生成
- 机制的技术边界： 我们必须重申在 控制面架构 中定下的边界：ReadyForAI 不做模型路由、不做动态模型网关、也不提供所谓「自动无感切换模型」的功能；此外，HeronSentry 的工具拒绝率指标仅在源端框架主动上报了对应字段时才可用。
故障形态七：企业知识库混入作废或冲突文档，Agent 依据过期条款错误执行
- 归属层级：Context · 时效与来源
- 典型形态：知识库中并存新旧两个版本的报销或风控规则，Agent 在 RAG 检索中命中了旧版文档切片，依据过期的宽松条款执行了违规报价。
- 为什么 Prompt 解决不了（责任放错层）：在 Prompt 中强调「遵循最新政策」无法解决 Context 层的证据时效问题。在向量相似度匹配中，模型无法凭空推理出哪一份切片在当前物理世界中具备有效性。
- 产品里真实对应的机制：
知识有效性必须落实为知识单元的原子化抽取、冲突扫描与调用链版本快照：
- LarkScout 矛盾扫描机制：知识资产平台 LarkScout 从非结构化文档中抽取结构化断言（Claim，主谓宾三元组），作为可引用的最小知识单元；引擎根据「同一主谓、不同宾语」的核心规则，自动扫描库中存在冲突的 Claim，并将其标记为
contradicted（已矛盾）或uncertain（存疑），在编译生成的知识视图中明确提示人工介入复核。 - HarnessServer 任务上下文快照与 Content Version：HarnessServer 在任务启动时记录当时所有可见内容的集合与版本，并在全链路 Trace 上打上
Content Version戳记，确保在事后审计时能够完整追溯 Agent 执行动作时所依据的确切知识版本。 - 双时态管理型记忆：HarnessServer 的双时态管理型记忆按照业务有效时间与系统记录时间进行双轴存储，支持按历史特定时间点精确回溯当时的数据视图。
- LarkScout 矛盾扫描机制：知识资产平台 LarkScout 从非结构化文档中抽取结构化断言（Claim，主谓宾三元组），作为可引用的最小知识单元；引擎根据「同一主谓、不同宾语」的核心规则，自动扫描库中存在冲突的 Claim，并将其标记为
- 机制的技术边界： 必须准确理解快照的内涵：HarnessServer 的任务上下文快照是用于审计追溯的结构化元数据记录，而不是对底层文件内容树进行的整包字节级物理冻结镜像；此外，双时态管理型记忆默认保持关闭状态，仅在显式配置时生效。
五、系统范式：Harness 的八条边界，我们覆盖到哪
在 Shuva Jyoti Kar 的系统框架中，运行时 Harness 被严格划分为八条关键边界。
为了给企业架构师提供一份真实可信的落地参考，我们必须坦诚拆解：在这八条边界中，ReadyForAI 的控制面产品覆盖了哪些、边界止于何处、以及哪项能力当前没有现成产品（动态凭据注入仍须自建或依赖外部密钥系统）。
| Harness 核心边界（外部框架） | ReadyForAI 产品现有的机制 | 出处与支撑能力 | 企业仍需自建或依赖底层的空缺（诚实说明） |
|---|---|---|---|
| 1. 持久状态（Persistent State） | PathPilot 持有任务状态、阶段流水线与预算状态；OwlAudit 审计链持有策略命中、人审决策与合规冻结；HarnessServer 快照持有上下文版本 | PathPilot 结构化任务与时间线；OwlAudit Hash Chain 账本；HarnessServer 上下文快照 | 恢复的是调度台账、外置任务状态与在归属校验及时限内可续接的会话；不承诺自动换 Worker 与自动重试。Worker 换人须走人工 reassign / handoff 路径，阶段重试仅限重跑本阶段。 |
| 2. 并发控制（Concurrency Control） | PathPilot 提供跨任务资源锁机制，避免多个并发任务对同一共享资源（如部署环境、版本分支）发生冲突 | PathPilot 资源锁 | 没有版本前置条件与写入租约拒绝机制。细粒度的行级数据写入冲突检测需由企业数据库或外部应用层实现。 |
| 3. 幂等动作（Idempotent Actions） | 跨服务写操作走幂等键去重：NodalOS 的身份写 RPC 以 (key, agent_id, method) 为作用域缓存并重放上次响应，重复请求不重复执行；PathPilot 在 Fabric 收件箱按 message_id 做请求级去重，先 claim 后处理并回放缓存结果 |
NodalOS 身份写 RPC 幂等键控；PathPilot Fabric 收件箱 message_id 请求去重 | 幂等仅在跨服务消息与写 RPC 入口层覆盖；系统不提供通用的 task + action + target_version 幂等键控；Agent 自定义工具对外部系统产生的副作用（如下单、发消息）不在此层保护范围，仍需工具执行器自行实现幂等。 |
| 4. 执行时策略（Execution-Time Policy） | OwlAudit 作为 NodalOS 已挂接 Hook 上的同步评估器；NodalOS CEL 策略引擎在执行挂接点对动作做运行时策略评估；策略与审计记录同事务递增双版本号 | OwlAudit 同步评估点与策略版本溯源；NodalOS CEL 策略引擎 | 通用 Ingest 仅记账不拦截；未挂接 Hook 的路径不走评估；NodalOS Worker 审批原语默认关闭。 |
| 5. 隔离与凭证（Isolation & Credentials） | 容器与操作系统级管控由可免费使用的底座 NodalOS 承载；管理型记忆仅限授权 Agent；LarkScout 知识接口默认关闭需 mTLS | NodalOS 运行时管控；HarnessServer 双时态记忆隔离；LarkScout 知识接口 | 没有产品化的动态密钥注入机制。系统不负责在不经由模型上下文的前提下向私有工具隐式注入生产凭证，密钥分发需依赖外部 Secret Manager。 |
| 6. 故障恢复（Recovery） | NodalOS 侧：Coordinator 调度台账写入周期快照、重启后通过收件箱重放与 WAL 交叉恢复，进程按策略重新拉起，Worker 会话在归属校验与时限内可通过厂商 transcript 句柄续接；PathPilot 侧：任务、阶段、时间线全部外置持久化于数据库，崩溃后由定时对账任务收敛，并区分可重试的瞬时失败与需升级的业务失败 | NodalOS 调度快照、WAL 恢复与会话续接；PathPilot 数据库外置状态与后台定时对账 | 系统不提供自动换 Worker 接力或基于检查点的自动重试引擎；快照不承诺恢复 Agent 内部记忆与思维上下文；Worker 换人仅提供人工 reassign 与 handoff 路径；流水线阶段重试仅限重跑本阶段。 |
| 7. 全链路观测（Observability） | HeronSentry 标准 OTLP 采集调用链、按 Agent / Program 聚合成本、TTFT、截断率与工具拒绝率；HarnessServer 在 Trace 戳记 Content Version；OwlAudit 记录策略版本与人审决策 | HeronSentry 标准 OTLP 接入；HarnessServer Trace 戳记；OwlAudit 决策留痕 | HeronSentry 仅观测告警、不执行阻断；工具拒绝率仅在源端上报时可用；工作流图转移与自动重试动作无专门追踪留痕。 |
| 8. 评测回放（Evaluation Replay） | 评测按内容版本开展：HarnessServer 支持候选与基线版本在同一批固定任务（真实或模拟）上成对重放，在隔离夹具中执行且不污染生产统计；评估结论按内容版本产出并挂接至 LarkScout 推广审批作为绿灯依据（证据不足时须填理由）；AULO 按内容版本关联评估结果与 Agent 绩效，辅助创作者决定后续修订；评估记录带 NodalOS 运行时版本与模型标识，成对重放严格控制变量 | HarnessServer 成对重放隔离夹具；LarkScout 推广审批门禁；AULO 内容版本评估关联面板 | 生产观察仅作佐证、不能单独放行；系统不做历史工单全量回放与影子运行；按版本切的绩效仅输出任务派生比率与聚合值，不生成平台级总分，且绩效严格不进入 Agent 上下文。 |
可靠性与正确性是两类截然不同的故障
在评估上述边界时，架构师必须牢记一条核心原则：可靠性与正确性是两类完全不同的故障模式。
- 可靠性（Reliability） 关注的是系统的健壮度：任务在遭遇容器崩溃、瞬时超时、外部并发冲突时，能不能维持状态、避免无限消耗并安全挂起？
- 正确性（Correctness） 关注的是决策的语义质量：模型的诊断是否有扎实的证据支持？是否排除了替代假设？生成的 SQL 逻辑是否严谨？调用的外部工具是否符合内控政策？
正如 Shuva Jyoti Kar 在文章中所指出的：「一个足够持久的系统，可以完美地重复一个错误的决定。」（"A durable system can repeat a bad decision perfectly."）
这就是为什么企业既不能退回到「靠 System Prompt 写作文来祈求正确性」的幻觉中，也不能迷信「有了沙箱和状态存储就万事大吉」。Prompt 与 Context 负责为单次决策提供精确的输入契约与证据约束；而 Harness 负责在执行那一刻兜底，让内部决策的意外不至于直接穿透企业的安全底线。
六、企业选型与自查：给架构师的九个硬核拷问
在进行企业 Agent 基础设施设计或采购验收时，建议技术负责人与架构师向方案提供方提出以下九个不容回避的硬核问题：
- 策略违规拦截发生在执行前还是执行后？ 系统能否在破坏性系统调用（如数据删除、大额资金拨付、越权修改）真正触达物理接口之前，通过底层的同步 Hook 机制将其拒绝？还是仅仅在动作执行完成后，在审计日志里轻描淡写地记上一行「已违规」？
- 运行时容器意外崩溃后，任务上下文是在内存中彻底蒸发，还是在外部状态库中拥有持久化流水线？ 当底层宿主机轮转、节点重启或网络断连时，系统是必须从头开始重跑任务并让此前消耗的算力全部报废，还是在运行时外部持有持久化的任务流水线与状态机？
- 当多 Agent 协同陷入争辩与死循环时，系统能否提供清晰的预算阶梯与超限审批？
面对由于逻辑冲突产生的无限调用，系统是否有类似于
normal/warning/degraded/exhausted的递进预算状态，并在额度耗尽时挂起、转入覆盖请求，而不是任由消耗继续直至账户欠费？ - 敏感数据防泄漏是依靠脆弱的输出正则过滤，还是在执行前就严格收敛了可见性边界？ 系统是在工具调用参数已经拼装完成后试图进行文本匹配拦截，还是由上下文分发中枢按照 Agent 角色权限，从一开始就将未经授权的代码、数据与管理型记忆从可见集合中剥离？
- 人工审批机制是粗暴的无差别弹窗，还是具备清晰的风险分级分流？ 系统是将所有工具调用无脑推给人类操作员导致审批疲劳与盲目全过，还是基于策略动作区分自主放行、事后监督与事前人审，并能严密追踪审批否决率与超时升级链？
- 当底层模型供应商发生协议调整或版本更迭时，系统是否具备框架无关的协议适配底座？ 更换底层推理后端或客户端开发框架时，是否需要推倒重写全套提示词与私有封装，还是底层具备统一纳管 5 类 RuntimeClass 的操作系统底座与字节稳定的配置文件生成能力？
- 当企业管理制度发生变更时，知识体系能否主动发现新旧矛盾，并提供精准的版本追溯？ 面对新旧并存的制度文档，系统能否在知识提炼阶段主动扫描主谓宾断言之间的逻辑冲突，并在每一次任务调用链的 Trace 上清晰记录当时上下文的 Content Version？
- 系统各层的工程制品是否实现了独立版本化？ 升级底层模型会不会莫名改变系统的执行权限？修改检索逻辑是否经过了针对「证据缺失」或「无信号」边缘用例的专项回归验证？
- 任务完成的最终裁决权归谁？ 是模型在输出文本里轻率地宣布「我已经做完了」，还是由外部控制面按照图状态机、已验证的证据链条与成功的外部副作用回执来客观判定？
七、结语：从提示词作文走向系统工程
在软件工程演进的历程中，每一次抽象层级的跃升，都伴随着从「依靠人为谨慎」到「依靠机器与制度」的范式转变。
在编程语言刚刚诞生的年代，先驱们依靠极高的个人纪律来避免内存泄漏；然而软件工程真正走向成熟，靠的是类型系统、垃圾回收（GC）以及静态分析工具等坚固的基础设施。
今天的企业 Agent 落地正处于相似的历史十字路口：
- 依靠在 System Prompt 里字斟句酌地推敲词句、反复告诫模型保持克制，本质上是在用写作文的方式做系统设计。这种方式在实验室的受控演示中能够带来惊艳的表现，但在充满不确定性、恶意对抗与复杂调用链的真实生产世界里，它脆弱得不堪一击。
- 企业真正需要投入精力建设的，是 Prompt 之外的四层，尤其是最外层、决定执行能否被治理的运行时 Harness。
正如 Shuva Jyoti Kar 所总结的警醒之语：
「提示词依然重要，但它不是系统本身。」（"The prompt is still important. It is simply not the system."）
Prompt 负责指引方向，而 Harness 负责托底护航。只有当硬性策略门禁、预算状态机、分级人审链路、角色可见性边界与全链路观测各司其职，紧密扣合在企业数字劳动力的核心链路之中，Agent 才能真正摆脱提示词工程的脆弱浪漫，成长为能够承担企业关键业务负荷的生产级基础设施。
延伸阅读与相关专题：