论 AI 工程中的黑箱治理问题

JanYork_简昀

发布于 2026-03-30 17:21:17

1230

在阅读本文之前，为了避免概念混淆与适用范围误判，本文的讨论建立在以下前提之上：

本文所讨论的场景，是由 AI Agent 主导并承担端到端工程执行的软件开发过程，人工不直接介入具体技术实现。
文中所称“AI 工程”，特指由 AI Agents 驱动的软件工程系统，而非基础模型训练、算法研究或一般意义上的 AI 应用开发。
文中“人工不做技术介入”，是指人类不直接参与编码、调试、测试、任务拆解、实现路径选择等执行性技术环节；人工仍负责目标定义、约束设定、验收标准与风险兜底。
本文关注的核心问题是工程治理，即如何对黑箱系统的行为进行约束、验证、观测、隔离与演化控制，而非讨论模型内部机理是否可解释。
本文的分析对象主要是生产级、长链路、多步骤的 Agent 系统，不针对低风险辅助编程、一次性脚本生成或单轮问答式调用场景。

序

过去十年，软件工程的核心假设一直是稳定的。系统是确定性的，代码是可读的，行为是可推导的。

工程师通过阅读、推理和调试代码，建立对系统的控制与信任。这套机制在传统软件时代行之有效，并构成了现代工程体系的基础。

然而，随着大模型开始驱动核心软件生产流程，AI 主导的软件工程正逐步进入核心生产链路，这一假设正在被系统性打破。

AI 不再只是辅助工具，而逐渐成为生产系统的一部分。

它不仅生成代码，还参与决策、执行任务，甚至在某些场景中承担端到端的功能实现。这意味着，系统的一部分行为已经不再由人类直接编写，而是由一个复杂的、概率性的模型生成。

这带来了一个不可回避的问题：

工程控制权正在从“代码”转移到“系统行为”。

黑箱问题的工程本质

所谓“黑箱”，并不只是指我们看不到模型内部参数或推理路径。更准确地说，它描述的是一种工程状态。即系统的内部实现不可完全理解，但其外部行为必须被控制。

在传统软件中，黑箱通常是局部的。

例如，一个第三方库、一个服务接口、一个外包模块。这些组件虽然内部不可见，但其边界清晰、行为稳定，因此可以被纳入整体系统。

而在 AI 主导的软件工程中，其关键差异在于：

行为不是严格确定的
输出依赖上下文而非固定逻辑
同一输入在不同条件下可能产生不同结果

总而言之，AI 始终是不具备人一样的拥有高度智慧的决策和执行能力。这使得黑箱从“局部现象”演变为“系统特性”。

控制困境

传统工程中，控制的核心路径可以抽象为：

理解代码 → 推导逻辑 → 验证正确性 → 建立信任

这条路径依赖一个前提：代码与工程是可被深度理解的。

但在 AI 主导的软件工程中，这条路径断裂了。我们无法通过阅读模型权重或内部结构来理解系统行为。

即使是查看生成的代码，也只能看到结果，而无法还原其决策过程，这是其一。

其二是当系统代码量到达一定规模，AI 可以在短时间内产出大量的代码与大范围的改动，我们无法去花费大量的人力成本去一一审阅，这也违背了 AI Coding 的本意。

因此，传统控制逻辑变成：

（无法完全理解实现）
    ↓
无法通过理解建立信任
    ↓
控制机制失效

这就是当前工程实践中普遍存在的不适感来源：

开发者失去了“通过理解来控制系统”的能力。

从“理解实现”到“控制行为”

在这种背景下，问题本身需要被重新定义。

我们不再问，这段代码是怎么写出来的？

而应该问，这个系统的行为是否在可控范围内？

这看似是一个语义上的变化，但实际上是工程范式的根本转移。

新的问题结构可以表示为：

输入
    ↓
Agent Workflow
    ↓
输出

传统工程关注的是中间的实现过程，而 AI 主导的软件工程需要关注的是两端：

输入是否被约束
输出是否满足要求

以及整个过程是否可观测、可验证、可回放。

核心问题

基于上述背景，本文试图回答一个核心工程问题：

在无法完全理解系统实现的前提下，如何构建一个可控、可验证、可演化的 AI 主导的软件工程体系？

这个问题可以进一步拆解为三个子问题：

如何建立对黑箱系统的信任边界
如何在运行过程中持续控制系统行为
如何在系统演化中避免失控

这三个问题分别对应后文的：

认知与信任重构
分层治理架构
演化与反馈机制

范式转移，从代码中心到系统中心

为什么这个问题在结构上是不可避免的？

答案在于工程范式本身已经发生了变化。

传统软件工程的控制逻辑

传统软件工程的核心是“确定性系统”。

其基本特征包括：

输入与输出之间存在稳定映射
系统行为可以通过代码推导
修改代码可以精确改变行为

通俗来讲，也就是由技术负责人及团队对工程百分百把控。

控制路径可以抽象为：

代码
    ↓
逻辑
    ↓
行为

工程师通过修改代码，间接控制系统行为。

在这种模式下，“代码”既是实现载体，也是控制接口。

此类工程的结构性变化

AI 主导的软件工程采用了一种不同的计算范式：概率性生成。

其行为可以抽象为：

输入
    ↓
模型
    ↓
输出分布

这里的关键变化在于：

输出不是唯一确定值，而是一个随机分布
行为由统计模式驱动，而非显式逻辑
上下文成为影响结果的关键因素

这意味着，系统行为和工程实现不再完全由代码决定，而是由“模型 + 上下文”共同决定。

控制对象的变化

在这种新结构下，控制路径发生了根本变化。

传统路径：

控制代码 → 控制逻辑 → 控制行为

AI 主导的软件工程路径：

控制上下文 + 约束条件
        ↓
影响模型行为
        ↓
约束输出结果

可以用一个对比图表示：

传统系统：
[Code] → [Logic] → [Behavior]

AI 主导的软件工程：
[Context / Constraint]
         ↓
       [Model]
         ↓
     [Behavior]

这里最重要的变化是，控制接口从“代码”转移到了“上下文与约束”。

从可理解性到可治理性

在传统工程中，“理解”是控制的前提。

读懂代码 → 推导行为 → 判断正确性

但在 AI 主导的软件工程中，这条路径不可行。模型的内部结构复杂到无法完全解释，系统行为也无法通过静态分析完全预测。

因此，工程目标必须改变，从“让系统可理解”，转向“让系统可治理”。

两者的差异可以总结如下：

维度	传统工程	AI 主导的软件工程
控制方式	理解实现	约束行为
信任来源	代码阅读	验证机制
调试方式	Debug 代码	Debug 系统行为
稳定性来源	确定性逻辑	多层约束与验证

系统中心化的工程模式

在新的范式下，工程的核心不再是“写出正确代码”，而是“设计一个可控系统”，即如何更好的使用 AI 来完成工程研发本质是如何做好工程控制。

这个系统需要具备以下能力：

能限制 AI 的行为范围
能验证输出是否满足要求
能在运行中观测行为变化
能在出错时快速定位与回放

其结构可以抽象为：

    ┌─────────────────┐
    │   Constraint    │
    └────────┬────────┘
             ↓
    ┌─────────────────┐
    │      Model      │
    └────────┬────────┘
             ↓
    ┌─────────────────┐
    │    Behavior     │
    └────────┬────────┘
             ↓
    ┌─────────────────┐
    │   Validation    │
    └────────┬────────┘
             ↓
    ┌─────────────────┐
    │  Observability  │
    └─────────────────┘

这实际上就是一个控制系统，而不是一个单纯的软件模块。

认知与信任重构

在进入具体的工程治理之前，有一个更基础但往往被忽视的问题：

工程师是否在认知上接受黑箱系统。

如果这一层没有完成转变，后续所有治理机制都会在心理上被削弱，甚至被抵触。

因为在传统经验中，“看不懂”、“不用看” 往往等价于“不安全”，而 AI 主导的软件工程恰恰要求我们在“不完全理解”的前提下做出工程决策。

工程信任机制的历史依赖

软件工程中的“信任”从来不是抽象概念，而是建立在具体机制之上的。

在传统模式中，信任主要来源于三个路径：

代码可读性 → 逻辑可推导 → 行为可预测

开发者通过阅读代码理解系统，通过逻辑推导验证行为，通过测试确认结果。这三者构成了一个闭环，使得“信任”成为一种可操作的工程能力，而不是主观判断。

因此，开发者对代码产生依赖并不只是习惯，而是一种经过长期验证的控制方式。

“代码可见性”与“系统安全性”的误绑定

问题在于，这种依赖在 AI 主导的软件工程中被错误地延续了。

很多开发者在面对 AI 生成代码或系统行为时，会产生一种直觉判断：

如果我没有看过这段代码，我就无法保证它是安全的。

这实际上是一种认知误绑定，它把“是否看过代码”与“系统是否安全”直接关联起来，而忽略了中间真正起作用的机制。

我们换一个角度想想，企业的非技术管理人员或小公司的老板向技术员下发需求，随后技术员产出技术实现，也就是代码。这个过程对于非技术人员来说本质就是一个黑盒。

所以很多时候，我们需要从死板的程序编码转向工程与项目管理，从非技术视角来驱动项目。

在传统工程中，代码之所以带来安全感，并不是因为“看到了”，而是因为：

可以通过代码推导逻辑
可以通过逻辑预测行为
可以通过行为验证结果

也就是说，代码只是一个中介工具，而不是信任本身。

在 AI 主导的软件工程中，这个中介失效了，但很多人仍然把它当作必要条件，从而产生认知冲突。

从实现信任到验证信任

解决这一问题的关键在于完成一次认知解耦：将“实现的可见性”与“系统的可控性”分离。

新的信任路径不再依赖实现细节，而依赖验证机制：

约束
    ↓
执行
    ↓
验证
    ↓
信任

在这个路径中，信任的来源是：

明确的行为边界
可执行的验证标准
稳定的评估结果

而不是“是否亲自写过或看过代码”。

黑箱系统的可接受性边界

需要强调的是，这并不意味着可以无限制地接受黑箱。

黑箱系统之所以可以被工程接受，必须满足一个前提：它的行为处于可定义、可验证、可约束的范围之内。

这个范围可以称为信任边界。

可控区域
  [可验证行为]
       ↑
   信任边界
       ↑
不可控 / 未知区域

工程的目标不是扩大黑箱，而是：

明确边界在哪里
确保系统运行在边界之内
一旦越界能够被检测并阻断

信任的重新定义

在这一框架下，“信任 AI” 本身是一个不严谨的说法。

更准确的表达应该是：工程师并不信任 AI 本身，而是信任围绕 AI 构建的治理系统。

这一定义带来一个重要转变：

信任对象从“模型能力”转向“系统设计”
风险控制从“理解内部”转向“约束外部行为”

这也是后续所有工程方法成立的基础。

黑箱治理的基本原则

在完成认知层转变之后，接下来需要回答的问题是：一个黑箱系统在工程上“可控”，意味着什么？

答案不是单一指标，而是一组系统性原则。这些原则构成了黑箱治理的基础约束，也是后续架构设计的判断标准。

可约束性

可约束性是所有治理能力的前提。

如果一个系统的行为无法被限制，那么后续的验证、观测和优化都没有意义。因为系统可以在任何方向上偏移。

在 AI 主导的软件工程中，约束主要体现在三个方面：

输入约束：限制 AI 接收的信息结构
行为约束：限制 AI 可执行的操作
输出约束：限制 AI 必须满足的结果形式

可以用一个简化结构表示：

Input Constraint → AI-led Workflow → Output Constraint

约束的目标不是减少能力，而是缩小不确定性空间。

可验证性

约束定义了“不能做什么”，验证则定义了“做得对不对”。

在黑箱系统中，验证不再依赖内部逻辑，而依赖外部标准。常见形式包括：

单元测试与端到端测试
不变量检查
基准数据集评估

验证的关键在于定义“正确”的标准，而不是解释“为什么正确”。

可观测性

即使系统被约束且通过验证，如果运行过程不可观测，仍然无法进行有效治理。

可观测性关注的是：

系统在运行时做了什么
决策路径如何形成
哪一步出现偏差

在 AI 主导的软件工程中，可观测对象不仅包括输出，还包括：

输入上下文
中间决策
系统状态变化

一个典型的观测结构如下：

Input → [Trace] → Decision → [Trace] → Output

可观测性为调试、审计和优化提供基础数据。

可演化性

AI 主导的软件工程体系不是静态的。模型更新、prompt 调整、策略变化都会影响行为。

因此，系统必须具备可演化性：

修改后行为不会失控
不同版本可以对比
出现问题可以回滚

这要求：

版本控制
评估驱动更新
渐进式发布（如灰度）

可演化性保证系统在长期运行中保持稳定，而不是在每次调整后重新进入未知状态。

原则之间的关系

这四个原则并不是独立存在的，而是构成一个闭环系统：

Constraint → Execution → Observation → Validation → Evolution

约束定义边界
执行产生行为
观测记录过程
验证判断结果
演化优化系统

如果缺少其中任何一环，系统都会出现结构性风险。

控制目标的重新定义

在这些原则之上，可以对“控制”给出一个更精确的工程定义：

控制并不意味着决定每一个执行细节，而是确保所有可能行为都落在可接受范围内。

这一定义与传统工程有本质不同：

传统控制强调确定性
黑箱治理强调边界与分布

换句话说，工程师不再控制“路径”，而是控制“空间”。

分层治理架构

上述解决了两个问题：

第一，我们为什么必须接受黑箱。第二，我们应该用什么原则去治理黑箱。

接下来进入核心问题：

具体如何构建一套可控的 AI 主导的软件工程体系？

答案不是单一机制，而是一套分层控制架构。

其本质类似操作系统或分布式系统中的控制面设计：不同层级负责不同维度的约束与控制，共同形成一个稳定的整体。

架构总览

整个治理体系可以抽象为一个多层控制结构：

    ┌─────────────────────────┐
    │   Cognitive / Trust     │
    ├─────────────────────────┤
    │   Constraint Layer      │
    ├─────────────────────────┤
    │   Structural Layer      │
    ├─────────────────────────┤
    │ Execution & Observation │
    ├─────────────────────────┤
    │ Validation & Evaluation │
    ├─────────────────────────┤
    │  Evolution & Feedback   │
    └─────────────────────────┘

每一层解决一个不同维度的问题：

上层定义“是否接受”
中层定义“如何控制”
下层定义“如何验证与优化”

这些层不是串行流程，而是共同作用于系统运行的控制网。

认知与信任层

这一层不是技术实现，而是工程前提。

如果团队仍然坚持“必须看代码才安全”，那么任何黑箱治理机制都会被绕过或弱化。

这一层的核心输出只有两个：

明确信任边界
定义最低可接受标准

例如：

所有核心流程必须可回放
所有关键输出必须可验证
所有外部调用必须可追踪

这实际上是在回答，在什么条件下，我们允许系统运行？

行为约束层

这是最关键的一层之一，因为它决定了系统的行为空间大小。

如果这一层设计不当，后续所有层都会被放大压力。

契约控制

契约的作用是将 AI 的“自由输出”转化为“结构化输出”。

例如：

自由文本 → JSON Schema → 可验证结构

契约的价值在于：

消除歧义
限制输出形式
为验证提供基础

能力边界

AI 默认是“全能生成器”，但工程系统不能允许无限能力。

必须明确：

能调用哪些工具
能访问哪些资源
能执行哪些操作

一个典型结构：

    ┌──────────────────┐
    │        AI        │
    └────────┬─────────┘
             ↓
    ┌──────────────────┐
    │ Tool Whitelist   │
    └────────┬─────────┘
             ↓
    ┌──────────────────┐
    │ External Systems │
    └──────────────────┘

能力控制的目标是：防止错误被放大为事故。

语义约束

这是很多系统缺失但极其关键的一层。

结构正确并不代表语义正确。

例如：

JSON 合法，但业务逻辑错误
SQL 可执行，但查询意图错误

语义约束关注的是，输出是否“符合业务意义”

通常通过：

规则系统
二次校验模型
业务不变量

来实现。

鲁棒性约束

AI 最大风险之一来自“分布外输入”。

即系统面对未见过的输入时行为失控。

鲁棒性约束的目标是：

限制输入空间
检测异常输入
在不确定情况下降级或拒绝

系统结构层

如果约束层定义“边界”，那么结构层定义“组织方式”。

错误的结构会让系统复杂度指数级增长。

架构分层

避免单一 Agent 处理所有任务，而是进行职责拆分。

典型结构：

Planner → Executor → Verifier

这样可以：

降低单点复杂度
提高可解释性
增强可控性

决策分解

AI 不应该一次性完成所有决策，而应拆分为多步：

Task → Plan → Subtasks → Execution → Validation

这使得每一步都可以被独立控制与验证。

状态治理

AI 主导的软件工程往往表现为“隐式有状态”。

问题在于：

状态容易污染
上下文会漂移
历史信息影响未来决策

因此必须显式管理：

状态定义
状态转移
状态生命周期

例如：

Draft → Review → Approved → Published

隔离机制

隔离用于限制错误影响范围。

常见方式包括：

Agent 沙箱
任务级隔离
权限隔离

目标是，局部错误不会演变为系统性故障

执行与观测层

这是系统运行时的控制核心。

推理监控

传统系统只看输入输出，而 AI 主导的软件工程需要关注中间过程本身。

例如：

为什么调用这个工具
为什么做出这个决策

推理监控可以帮助发现：

错误路径
异常策略
潜在风险

行为观测

观测包括三个层面：

输入
行为
输出

一个完整链路：

Input → Trace → Decision → Trace → Output

运行控制

运行层负责控制上线风险：

灰度发布
A/B 测试
限流 / 熔断

这使得系统变化不会立即影响全量用户。

验证与评估层

正确性验证

单次结果是否正确？

手段包括：

单元测试
端到端测试
不变量校验

系统评估

系统整体是否变好或变差？

例如：

准确率
成功率
错误分布

审计与回放

必须能够：

重放历史行为
对比不同版本
追溯错误来源

否则系统不可治理。

演化与反馈层

激励机制

AI 会优化它“认为重要的东西”。

如果没有明确激励，它可能优化：

表面正确
回答速度
避免报错

而不是实际质量。

因此需要：

reward / penalty
failure-driven learning

持续演化

系统必须支持：

prompt 版本化
模型切换
策略更新

反馈闭环

完整闭环如下：

Execution → Observation → Evaluation → Update → Execution

黑箱系统的失效模式与风险结构

系统会如何失效？

理解失效模式，是构建可靠系统的前提。

语义正确但逻辑错误

这是最隐蔽的一类错误。

表现为：

输出结构正确
格式合法
甚至测试通过

但业务逻辑错误。

例如：

返回正确格式的数据，但计算方式错误
调用了正确 API，但参数含义错误

问题本质是，结构验证无法覆盖语义正确性

状态漂移与上下文污染

AI 主导开发流程在长链任务中，往往会逐渐偏离原始目标。

原因包括：

上下文累积误差
历史信息污染
隐式状态不可控

可以表示为：

Initial Goal → Step1 → Step2 → Step3 → Drift

最终结果与初始目标偏离。

测试规避与策略性行为

随着模型能力提升，会出现一种新风险：AI 学会“通过测试”，而不是“完成任务”。

表现为：

针对测试用例优化
避开检测逻辑
输出“看起来正确”的结果

这类似于：

reward hacking
benchmark overfitting

分布外输入

AI 在训练数据之外的输入上表现不稳定。

问题包括：

极端输入
模糊输入
对抗输入

这些情况往往不会出现在测试集中，但会出现在真实环境中。

推理不可观测风险

如果系统无法观测推理过程，就无法解释错误。

问题表现为：

输出错误但原因不明
无法定位问题步骤
无法修复系统

激励错配

AI 优化的目标与工程目标不一致。

例如：

优化速度而非正确性
优化通过率而非质量
优化形式而非内容

可以表示为：

Expected Goal ≠ Optimized Goal

失效模式之间的关系

这些问题并不是独立的，而是相互影响：

State Drift → Wrong Context → Semantic Error
                   ↓
      Evaluation Failure → Incentive Distortion

一旦系统进入错误路径，可能形成连锁反应。

验证边界与工程方法论

上述分析了黑箱系统的主要失效模式，本节要解决一个更现实的问题：

在这些不可避免的不确定性之下，我们究竟能够“验证到什么程度”？以及，工程上应该如何构建一套可落地的方法体系？

这实际上是在给“信任”划定一个工程边界。

为什么测试永远不完备

在传统软件工程中，我们往往默认一个隐含前提：系统是可以被充分测试的。

但在 AI 主导的软件工程中，这个前提并不成立。

原因在于：

输入空间是开放的
输出是概率分布而非确定值
上下文组合呈指数级增长

可以用一个简化模型表示：

Input Space     → 无限
Context Space   → 组合爆炸
Behavior Space  → 不可穷尽

因此，不存在“覆盖全部情况”的测试体系。

概率系统 vs 确定性系统

为了理解验证的边界，需要区分两类系统：

特性	确定性系统	概率系统
输入输出关系	固定映射	分布映射
可预测性	高	有限
测试覆盖意义	强	有限
错误模式	可枚举	不可穷尽

在概率系统中，测试的作用不是“证明正确”，而是“估计风险”。

“测试通过”的工程语义重定义

因此，“测试通过”必须被重新定义。

传统语义：测试通过 = 系统是正确的

AI 主导的软件工程语义：测试通过 = 在已知样本空间内，系统行为处于可接受范围

这意味着测试本身只是信任体系的一部分，而不是最终结论。

构建多层验证体系

既然单一测试无法覆盖全部情况，就必须构建多层验证结构。

可以抽象为：

Level 1  → 单元验证
Level 2  → 端到端验证
Level 3  → 不变量校验
Level 4  → 对抗测试
Level 5  → 在线评估

每一层解决不同问题：

单元验证：局部正确性
端到端验证：流程正确性
不变量：关键约束不被破坏
对抗测试：边界情况
在线评估：真实环境表现

从构建到运行

在实践中，黑箱治理需要一套系统化方法，而不是零散措施。

可以归纳为五个步骤。

目标定义与约束建模

所有系统必须从明确目标开始。

核心问题包括：

系统要完成什么任务
什么行为是不可接受的
输出必须满足哪些约束

这一步决定了后续所有机制的方向。

权限与能力设计

在目标确定后，需要明确 AI 的操作边界：

可调用工具集合
可访问数据范围
操作权限级别

目标是将系统能力限制在“安全可控范围”内。

多层验证体系构建

将前面提到的验证层落地为具体系统：

自动化测试框架
不变量校验器
对抗测试集
评估指标体系

关键在于，验证必须是持续运行的，而不是上线前一次性完成。

可观测与审计系统设计

系统必须具备以下能力：

全链路日志记录
trace 跟踪
prompt / context 存档
replay 能力

一个典型结构：

Execution → Log → Trace → Storage → Replay

演化与版本控制机制

AI 主导的软件工程体系会持续变化，因此必须设计：

prompt 版本管理
模型切换策略
灰度发布机制
回滚能力

目标是：每一次变化都是可控的，而不是“重新开始”。

行业趋势与未来工程形态

在前面的章内容中，我们构建了一套完整的黑箱治理理论与工程框架。

本节的目标是回答一个更宏观的问题：这些变化是否只是局部实践，还是正在成为整个行业的共识？

答案是明确的。

AI 主导的软件工程正在整体转向系统治理范式。

从模型能力到系统能力

早期 AI 发展的关注点是模型本身：

参数规模
训练数据
基准测试

但当前趋势已经发生转移，模型能力只是基础，系统能力才决定最终效果。

系统能力包括：

上下文控制
工具调用
多步推理
任务编排

从 Prompt Engineering 到 Context Engineering

早期工程实践中，重点在于 prompt 设计。

但随着系统复杂度提升，prompt 已经不再是唯一控制手段。

新的控制对象包括：

system prompt
memory
tool schema
examples
state

可以表示为：

Context = Prompt + Memory + Tools + State + Constraints

这意味着，控制 AI 的核心，不是单一输入，而是整个上下文系统。

LLM Observability 与评估体系

随着系统复杂度提升，观测能力成为基础设施。

核心组件包括：

logging（日志）
tracing（调用链）
metrics（指标）
evaluation（评估）

其作用类似传统系统中的监控平台，但复杂度更高。

多 Agent 系统与状态复杂性

未来系统将越来越多地采用多 Agent 架构：

Agent A → Agent B → Agent C
   │         │
   ↓         ↓
 Tool     Memory

这种结构带来两个变化：

决策链变长
状态管理复杂度大幅提升

这进一步强化了状态治理成为核心能力

AI 监督 AI

一个重要趋势是，使用 AI 来评估和监控 AI

典型应用包括：

自动评估输出质量
检测异常行为
审核决策过程

这使得系统可以在没有人工干预的情况下持续运行。

系统边界问题

随着 AI 主导的软件工程与外部环境的交互增加，新的风险开始出现：

输入中包含恶意指令
数据被误当作指令执行
工具调用被操控

这些问题本质是系统边界不清晰。

因此必须加强：

输入隔离
权限控制
行为校验

AI 主导的软件工程

综合所有趋势，可以对未来工程形态做出一个判断：软件工程正在从“构建程序”，转向“设计控制系统”。

这个系统的核心职责不再是执行逻辑，而是：

管理不确定性
控制行为边界
维持系统稳定

工程能力的转型

这一变化对工程师提出新的能力要求：

传统能力：

编码
调试
算法实现

新能力：

系统设计
约束建模
风险控制
评估体系构建

结论

本文的最终结论可以总结为一句话。

对 AI 主导的软件工程而言，核心不再是写出正确的代码，而是构建一个始终可控的系统。

黑箱不是问题，失控才是问题。

工程的任务也从“理解内部”转向“控制整体”。

当这一转变完成时，黑箱将不再是阻碍，而是系统能力的一部分。

注释

Agentic System：以大模型为核心执行体，在环境反馈回路中持续进行决策、工具调用、状态更新与结果输出的系统。本文重点指可跨多步执行、具备一定自主性的系统，而非单轮对话模型。
Workflow：由预定义控制流编排的执行流程，其核心是“代码规定路径，模型完成局部判断”。相较完全自主的 Agent，其可预测性通常更强。
Context Engineering：围绕系统指令、工具描述、检索结果、示例、记忆、状态摘要与消息历史进行整体设计、裁剪与压缩的工程实践，本质上是对模型决策条件的工程化控制。
Trust Boundary：系统可接受行为的边界定义。超出边界的行为不应被默认执行，而应被拦截、降级、回退或升级到人工审核。
Invariant：不变量。无论推理路径、工具组合或执行轮次如何变化，系统都必须持续满足的约束，例如权限不得越界、关键数据不得泄露、输出必须满足结构约束。
Sandboxing / Isolation：通过运行环境隔离、权限最小化、资源边界限制与任务拆分，将错误影响控制在局部范围内的机制。
Observability：可观测性。对输入、工具调用、状态变化、决策轨迹、输出结果与运行指标进行记录、关联与分析的能力。
Trace：执行轨迹。一次 Agent 运行过程中完整的消息、推理、工具调用、返回结果与状态变化记录，是审计、回放与系统级调试的基础。
Trace Grading：对执行轨迹中的关键步骤进行结构化评分，不只检查最终输出，也评估中间决策、工具使用质量与偏差位置。
Eval-driven Development：以评估先行或评估伴随的方式定义目标能力、边界条件与回归标准，并据此驱动 prompt、tool、workflow 与 model 的持续迭代。
Out-of-Distribution：分布外输入。偏离训练分布或验证样本分布的输入类型，往往是 Agent 失稳、误判或越界行为的重要来源。
Prompt Injection：提示注入。攻击者将恶意指令嵌入不受信任内容中，诱导模型覆盖原有约束并改变行为；在工具调用、检索增强与多 Agent 系统中风险尤其突出。
AI-as-a-Judge：使用模型对模型输出、行为轨迹或候选结果进行打分、排序或审查的方法。其优势是可扩展，但仍需元评估、校准与人工抽检来保证可靠性。