Operating Mode as Runtime State: A Contract for Enterprise将运行模式作为运行时状态：企业的一项契约

During a service incident, a customer-remediation workflow is moved onto an emergency route because the situation is critical and the team needs a fast resolution. Approvals are shortened, a priority queue is opened, and an on-call agent is cleared to use an alternate procedure until the service recovers. The incident ends, but the route stays active for a small customer segment after everyone has moved on.在服务事件期间，由于情况危急且团队需要快速解决问题，客户补救工作流会被转移到紧急路由上。审批流程被缩短，优先级队列被开启，值班代理被授权使用替代程序，直到服务恢复。事件结束后，尽管相关人员已转入其他工作，但该路由仍对一小部分客户保持激活状态。

The emergency route itself was fine. Production systems need emergency routes, and a human approved this one. The trouble is that the route now runs without a live incident, an owner, or an expiry condition. A controlled exception has quietly settled into the platform’s standard runtime behavior.紧急路由本身并无问题。生产系统需要紧急路由，且此路由经过了人工审批。问题在于，该路由现在在没有实时事件、负责人或过期条件的情况下运行。一个受控的异常已经悄然沉淀为平台的标准运行时行为。

This article is about that execution layer: the temporary operating state that lingers in runtime behavior. Temporary authority is easy to grant under pressure and hard to retire once the pressure lifts. An enterprise agent shouldn’t have to guess from prompts or conversation history whether it’s running under normal, incident, or recovery conditions. That state should be handed to it as authoritative runtime input, the way platforms already hand over identity, tenant, environment, and permissions.本文讨论的是执行层：即残留在运行时行为中的临时操作状态。在压力下授予临时权限很容易，但在压力消除后将其撤回却很难。企业智能体不应通过提示词或对话历史来猜测自己是在正常、事件还是恢复条件下运行。该状态应作为权威的运行时输入传递给它，就像平台处理身份、租户、环境和权限那样。

An exception is safe while the incident that justified it is live. It becomes dangerous the moment the platform can no longer show the incident has ended.异常在引发该异常的事件存续期间是安全的。一旦平台无法再证明事件已经结束，它就变得危险了。

The problem is unmanaged exception state问题在于未管理的异常状态

Exception drift is what happens when temporary exception behavior outlives its authorized scope, authority, or duration, and emergency accommodations settle into normal execution. The drift is usually quiet: a routing rule that stays reachable, an approval shortcut that survives closure, a tool permission that keeps shaping execution after the triggering condition has passed.异常漂移是指临时异常行为的存续时间超出了其授权范围、权限或期限，导致紧急应对措施固化为正常执行流程的现象。这种漂移通常是悄无声息的：一个保持可达的路由规则、一个在关闭后依然有效的审批捷径，或是一个在触发条件消失后仍继续影响执行的工具权限。

Enterprises already have the human machinery for this. Incident management defines abnormal conditions, change control governs deviations from standard practice, and postincident reviews confirm that temporary measures have closed.¹,² The gap is architectural. Most agent platforms still treat organizational operating state as something outside the runtime rather than an input to it.企业已经具备了处理此问题的机制。事件管理定义异常状况，变更控制管理偏离标准实践的行为，事后审查则确认临时措施已关闭。1,2 缺口在于架构层面。大多数智能体平台仍将组织操作状态视为运行时之外的事物，而非运行时的输入。

Once an accommodation proves useful, it fades into an invisible operating state. The routing rule stays enabled, the shortened approval path stays reachable, and the temporary queue keeps taking work. No dramatic model failure is required, only a platform with no reliable way to close runtime state.一旦某种应对措施被证明有用，它就会淡化为一种无形的运行状态。路由规则保持启用，缩短的审批路径依然可达，临时队列持续处理工作。这不需要模型发生剧烈故障，只需要平台缺乏可靠的方法来关闭运行时状态即可。

The practical question to ask is “Which operating mode is active for this workflow, this user, this segment, at this moment?” When the answer is left implicit, every agent, workflow, and tool gateway invents its own. Discussions of agent architecture tend to dwell on capabilities such as models, tools, and orchestration, yet production behavior depends just as much on runtime context: identity, tenant, environment, permissions, session state, policy, and tool access. One piece of that context is usually absent. The runtime knows who is acting and what they may do but not whether the organization is under normal conditions, incident response, recovery review, or a declared exception. Exception drift begins in that blind spot.需要提出的实际问题是：“对于当前工作流、当前用户、当前细分市场，此刻处于哪种运行模式？”当答案隐含时，每个智能体、工作流和工具网关都会自行定义。关于智能体架构的讨论往往侧重于模型、工具和编排等能力，但生产行为同样依赖于运行时上下文：身份、租户、环境、权限、会话状态、策略和工具访问。通常缺失的正是该上下文的一部分。运行时知道谁在操作以及他们可以做什么，但不知道组织当前是处于正常条件、事件响应、恢复审查还是已声明的异常状态下。异常漂移正是始于这一盲点。

The exception lifecycle异常生命周期

Organizations move through a predictable sequence: normal operations, incident declaration, a temporary exception window, closure review, and return to normal. Each stage answers a question, from why the exception exists and who authorized it to what evidence shows it’s no longer shaping execution. Most enterprises handle the front of that sequence well; they’re practiced at declaring incidents and authorizing workarounds. The hard part is the retirement: proving that the exception behavior actually disappeared.组织遵循可预测的序列：正常运行、事件声明、临时异常窗口、关闭审查以及恢复正常。每个阶段都回答一个问题，从异常存在的原因和授权人，到证明其不再影响执行的证据。大多数企业在序列的前端处理得很好；他们习惯于声明事件和授权变通方案。困难的部分在于退出：证明异常行为确实已经消失。

Declaring an exception is loud. Retiring one is quiet, especially when the workaround improved throughput or helped the team recover faster. That asymmetry is where drift lives, because an incident can be closed on paper while emergency routing, override policies, or alternate workflows keep influencing execution. From the platform’s point of view, the lifecycle should close only when it can show that every exception path has been retired or formally adopted through change governance.声明异常是显性的，而撤销异常则是隐性的，尤其是当变通方案提高了吞吐量或帮助团队更快恢复时。这种不对称性正是漂移滋生的地方，因为事件可以在纸面上关闭，而紧急路由、覆盖策略或替代工作流却继续影响执行。从平台的角度来看，只有当它能证明每个异常路径都已撤销或通过变更治理正式采纳时，生命周期才应关闭。

Why this matters more for AI agents为什么这对 AI 智能体更为重要

Agents raise the stakes because they act. Rather than sitting in a config file, they select tools, trigger workflows, coordinate with other agents, and adapt their paths at runtime. An accommodation introduced during an incident can spread through routing, tool use, approval paths, and downstream agents. A traditional exception stays legible in a runbook or workflow definition; an agent can carry the same exception along many paths at once, which makes it harder to find and retire.智能体提高了风险，因为它们会采取行动。它们不是停留在配置文件中，而是选择工具、触发工作流、与其他智能体协作，并在运行时调整路径。在事件期间引入的应对措施可能会通过路由、工具使用、审批路径和下游智能体扩散。传统的异常在运行手册或工作流定义中清晰可见；而智能体可以同时沿多条路径携带相同的异常，这使其更难被发现和撤销。

For engineers, the missing layer is an authoritative operational-state context that arrives with the request rather than being inferred from it. Historical traces and retained memory can explain why an accommodation once existed. They should never decide whether it’s still authorized. Memory informs execution; operating mode governs it. And when the two disagree, authoritative runtime state wins.对于工程师而言，缺失的层级是一个权威的操作状态上下文，它应随请求一同到达，而不是从请求中推断出来。历史痕迹和保留的记忆可以解释为什么曾经存在某种应对措施，但不应决定它是否仍然被授权。记忆告知执行，运行模式管理执行。当两者发生冲突时，权威的运行时状态胜出。

A small example shows the shape of that context. It carries the minimum needed to bind an exception to a mode, a scope, an authority, an expiry, and a status:一个小例子展示了该上下文的形态。它承载了将异常绑定到模式、范围、权限、过期时间和状态所需的最少信息：

{
  "mode": "incident",
  "exception_id": "INC-4721",
  "scope": {
    "segment": "premium-customers",
    "region": "us-east",
    "workflow": "customer-remediation"
  },
  "authority": "service-owner",
  "expires": "incident-close",
  "status": "active"
}

The pattern sits near familiar ones without matching them. Feature-flag platforms such as LaunchDarkly target behavior by context, RBAC governs what a principal may do, and tenancy metadata tells a service where a request belongs.³ Operating mode serves a different purpose. It doesn’t replace policy, permissions, or memory: Permissions determine who may act, and policies determine how they may act. Operating mode determines whether exception behavior is authorized at all. As a result, it acts as a higher-order governance constraint on agents, workflows, approvals, tools, and escalation paths. Operating mode draws its authority from the organization’s incident and change process and represents a governed state of the enterprise, consumed by the runtime.该模式处于熟悉的模式附近，但并不完全匹配。诸如 LaunchDarkly 之类的功能标志平台通过上下文定位行为，RBAC 管理主体可以执行的操作，租户元数据告诉服务请求所属的位置。3 运行模式服务于不同的目的。它不能替代策略、权限或记忆：权限决定谁可以行动，策略决定他们如何行动。运行模式决定异常行为是否被授权。因此，它作为一种更高阶的治理约束，作用于智能体、工作流、审批、工具和升级路径。运行模式的权威性源于组织的事件和变更流程，代表了一种由运行时消费的、受治理的企业状态。

A design pattern for exception-aware agents一种异常感知智能体的设计模式

Operating mode becomes actionable once the platform treats it as a first-class runtime construct. Most agent architectures already inject identity, permissions, tenant context, and policy into every request, and operating mode belongs in that set. Agents consume it as authoritative state after the organization declares the exception, scopes it, assigns authority, and sets an expiry, instead of reconstructing it from prompts or accumulated context.一旦平台将运行模式视为一等运行时构造，它就变得可执行。大多数智能体架构已经将身份、权限、租户上下文和策略注入到每个请求中，而运行模式也属于这一集合。智能体在组织声明异常、划定范围、分配权限并设置过期时间后，将其作为权威状态进行消费，而不是从提示词或积累的上下文中重构它。

That reframes the architectural question as whether the platform can guarantee that exception behavior is impossible outside an authorized operating mode. Emergency behavior exists because the platform enables it, and for no other reason. Table 1 shows the minimum contract that makes the boundary testable.这重新定义了架构问题：平台能否保证在授权的运行模式之外，异常行为是不可能的？紧急行为之所以存在，是因为平台启用了它，别无他因。表 1 展示了使边界可测试的最简契约。

A workflow invocation receives that state alongside the user request, and orchestration, routing, and tool gateways read the same state. Figure 1 shows the shape.工作流调用与用户请求一起接收该状态，编排、路由和工具网关读取相同的状态。图 1 展示了其形态。

Building an exception-aware control plane构建异常感知的控制平面

The natural home for operating mode is an external control plane. Incident management platforms, maintenance window services, and change management workflows already hold authoritative operational state, and exception-aware architectures extend those signals into execution with explicit scope, authority, expiry, and closure semantics.⁴,⁵ Implementation will vary across organizations, but the principle holds: Exception state should be authoritative, observable, and externally managed, kept out of prompts and workflow definitions and away from agent memory.运行模式的天然归宿是外部控制平面。事件管理平台、维护窗口服务和变更管理工作流已经持有权威的操作状态，而异常感知架构将这些信号扩展到执行中，并具有显式的范围、权限、过期和关闭语义。4,5 实现方式在不同组织间会有所不同，但原则不变：异常状态应该是权威的、可观察的且由外部管理的，保持在提示词和工作流定义之外，并远离智能体记忆。

Exception-aware execution异常感知执行

With explicit operating state, behavior shifts when system state shifts, and prompt wording stops being the lever. Under normal operations, agents run standard workflows, routing, and approvals. Under incident mode, the same workflows can expose scoped accommodations that the authorized mode makes available, such as expedited approvals, alternate routing, deferred reviews, or emergency runbooks.有了显式的运行状态，当系统状态发生变化时，行为也会随之改变，提示词措辞不再是杠杆。在正常运行下，智能体执行标准工作流、路由和审批。在事件模式下，相同的工作流可以暴露授权模式所提供的范围化应对措施，例如加急审批、替代路由、延迟审查或紧急运行手册。

Table 2’s payoff is testability. A workflow in normal mode should never reach an emergency path, and a workflow in incident mode should reach only the accommodations its scope, authority, and expiry allow. Governance becomes an enforceable runtime property the platform can check at execution time.表 2 的价值在于可测试性。正常模式下的工作流绝不应触达紧急路径，而事件模式下的工作流应仅触达其范围、权限和过期时间所允许的应对措施。治理成为平台可以在执行时检查的可强制执行的运行时属性。

Return to the opening incident. With operating mode as runtime state, the emergency route opens only inside a declared exception: scoped to the affected segment and workflow, owned by the service owner, and stamped with an expiry tied to incident closure. When the incident closes, the mode returns to normal and the routing gate stops handing that route to the segment, ahead of any manual cleanup. Closure then runs as a check. The platform replays the exception’s scope against live routing, approval, tool, and queue configuration, and confirms that no path still resolves to the emergency behavior. No one has to remember to retire the route; it was bounded by state, and the platform can show it is gone.回到开头的事件。将运行模式作为运行时状态，紧急路由仅在声明的异常内部开启：限定在受影响的细分市场和工作流中，由服务所有者负责，并贴上与事件关闭相关的过期时间戳。当事件关闭时，模式恢复正常，路由网关停止向该细分市场提供该路由，无需人工清理。关闭动作随后作为一种检查运行。平台根据实时路由、审批、工具和队列配置对异常范围进行回放，并确认没有路径仍解析为紧急行为。没有人需要记得去撤销路由；它受状态约束，且平台可以证明它已消失。

A common operating model for multi-agent systems多智能体系统的通用运行模型

The problem compounds across collaborating agents. Customer-facing, orchestration, and execution agents may share a workflow while disagreeing about state, so one keeps applying emergency routing after another has returned to standard controls. A shared operating state gives them a single governance boundary: The exception is represented once and read consistently everywhere. As agent ecosystems grow more autonomous, shared operational state matters as much as shared identity and authorization. Fragmented state produces fragmented accountability.这个问题在协作智能体中会加剧。面向客户的智能体、编排智能体和执行智能体可能共享一个工作流，但对状态的理解不一致，导致一个智能体在另一个智能体恢复标准控制后仍继续应用紧急路由。共享的运行状态为它们提供了一个单一的治理边界：异常被表示一次，并在各处被一致读取。随着智能体生态系统变得更加自主，共享的操作状态与共享的身份和授权同样重要。碎片化的状态会导致碎片化的问责制。

Making exception drift observable使异常漂移可观察

The payoff is observability. These conditions have historically been hard to see because accommodations scatter across workflow definitions, approval policies, routing configurations, and tool permissions. Explicit operating state makes them measurable at runtime. Closure can trigger automated validation, and the platform can watch for residual exception behavior between closures. The revealing checks are direct: Is the exception’s routing path still reachable, do its temporary approvals or elevated permissions still resolve, and does any expired exception still touch behavior? Tracking how many exceptions are open, how long they stay open, and how often they harden into permanent change turns drift from an audit finding into a monitored signal.其回报是可观察性。这些状况在历史上很难被发现，因为应对措施分散在工作流定义、审批策略、路由配置和工具权限中。显式的运行状态使其在运行时可测量。关闭操作可以触发自动化验证，平台可以监测关闭之间的残留异常行为。揭示性的检查非常直接：异常的路由路径是否仍可达，其临时审批或提升的权限是否仍有效，以及是否有任何过期的异常仍在影响行为？跟踪有多少异常处于打开状态、它们保持打开的时间长度，以及它们固化为永久变更的频率，将漂移从审计发现转变为可监测的信号。

From adaptive agents to governed systems从自适应智能体到受治理系统

Table 3 captures the shift. Traditional governance documents exceptions and trusts that they are retired. An exception-aware platform represents them as runtime state that can be propagated, validated, monitored, and closed.表 3 捕捉了这一转变。传统治理记录异常并信任它们会被撤销。异常感知平台将其表示为可在运行时传播、验证、监测和关闭的运行状态。

The test is whether the platform can demonstrate that the exception stayed bounded to its purpose and duration.测试标准在于平台能否证明异常被限制在其目的和期限内。

None of this demands a new governance model. Organizations already know how to govern identity, permissions, change, and operational risk, and the recommendation is to extend those disciplines to operating state. Once operating mode is authoritative, observable, and testable, drift becomes detectable, closure verifiable, and recovery an engineering result. The aim is a platform that can make its own operating conditions explicit, hold every agent to them, and demonstrate a clean return to normal. In that model, temporary accommodations stay temporary, governance lives in the architecture, and enterprise agents earn trust at scale.这一切都不需要新的治理模型。组织已经知道如何治理身份、权限、变更和操作风险，建议是将这些准则扩展到运行状态。一旦运行模式是权威的、可观察的和可测试的，漂移就变得可检测，关闭变得可验证，恢复成为一种工程结果。目标是构建一个能够使自身运行条件显式化、让每个智能体遵守这些条件，并展示干净地恢复正常的平台。在该模型中，临时应对措施保持临时性，治理存在于架构中，企业智能体从而实现规模化信任。

References参考文献

1. ISO, “ISO 22301:2019: Security and resilience—Business continuity management systems—Requirements,” International Organization for Standardization, 2019. https://www.iso.org/standard/75106.html ↩︎ISO, “ISO 22301:2019: 安全与韧性——业务连续性管理系统——要求,” 国际标准化组织, 2019. https://www.iso.org/standard/75106.html ↩︎
2. Axelos, “ITIL 4: Change enablement,” IT service management practice, 2019. https://www.axelos.com ↩︎Axelos, “ITIL 4: 变更赋能,” IT 服务管理实践, 2019. https://www.axelos.com ↩︎
3. LaunchDarkly, “Target with Flags,” LaunchDarkly Documentation. https://launchdarkly.com/docs/home/flags/target ↩︎LaunchDarkly, “使用标志进行定位,” LaunchDarkly 文档. https://launchdarkly.com/docs/home/flags/target ↩︎
4. ServiceNow, “Change Management,” ServiceNow Product Documentation. https://docs.servicenow.com ↩︎ServiceNow, “变更管理,” ServiceNow 产品文档. https://docs.servicenow.com ↩︎
5. PagerDuty, “Maintenance Windows,” PagerDuty Support Documentation. https://support.pagerduty.com/main/docs/maintenance-windows ↩︎PagerDuty, “维护窗口,” PagerDuty 支持文档. https://support.pagerduty.com/main/docs/maintenance-windows ↩︎