跳到主要内容

黑盒困境：当 AI 读不懂业务意图，它就只是个“外挂”

· 阅读需 8 分钟

引言​

在争相采用 AI 的浪潮中，许多工程团队撞上了南墙。他们通过 API 将强大的大语言模型（LLM）连接到代码库，编写了大量的提示词（Prompt），期望获得一个能像高级开发人员或业务操作员那样行事的智能 AI Agent。然而，他们得到的却是一个脆弱的“外挂”——一个会幻觉业务逻辑、无法在事务间保持状态，并且一旦底层 API 签名变更就会崩溃的聊天机器人。

问题不在于模型的智力，而在于架构。对于大多数 LLM 来说，你的应用代码是一个由文本构成的“黑盒”。AI 基于语法预测 Token，但它无法通过成千上万行命令式代码（Imperative Code），内在且直观地“看见”结构关系、数据流向或深埋其中的业务意图。

要超越简单的 Copilot 并构建稳健的企业级 Agent，我们必须重新思考软件架构，让业务意图变得机器可读。

“外挂”陷阱：为什么套壳模式会失效​

当前集成 AI 的主流范式是“套壳”（Wrapper）或“插件”（Plugin）方法。开发者将 AI 视为外部顾问，通过上下文窗口向其投喂代码片段或数据库架构，并要求其执行任务。

在生产环境中，这种方法面临三个致命的失败点：

  1. 上下文碎片化（Context Fragmentation）：LLM 无法实时摄取一个单体代码库来理解业务规则变更的涟漪效应。它只能看到你投喂给它的碎片。
  2. 语义坍塌（Semantic Collapse）：变量名和函数签名（如 update_user_v2）很少能传达完整的业务约束（例如，“如果账户被冻结，则不能更新用户”）。“意图”在业务需求和代码实现之间的转化过程中丢失了。
  3. 脆弱的集成（Fragile Integration）：当 AI 作为“外挂”时，它运行在系统的核心运行时之外。它盲目地触发 API。一旦系统结构发生变化，AI 的“心智模型”（即 Prompt）就会瞬间过时。

正如近期关于 Agent 工作流的行业分析所指出的，自主 Agent 的主要瓶颈不是推理能力，而是落地（Grounding）——即能够将 AI 的行动牢固地锚定在系统经过验证的状态和结构之上。

从“代码优先”到“结构优先”​

为了解决黑盒困境，架构师必须将应用结构从隐式概念（隐藏在架构师脑海中）提升为显式的一等公民，使其成为 AI 可以读取、查询和操作的对象。

命令式代码的问题​

在传统开发中，结构是隐式的。一个“客户”（Customer）实体可能定义在一个 SQL 表、一个 Python 类、一个 React 组件和三个不同的 API 端点中。对于 AI 来说，这是四个不相关的文本文件。它必须去猜测其中的关系。

解决方案：声明式结构​

AI 原生架构需要一种协议，让系统能够自我描述。系统不应让 AI 从代码中推断关系，而应暴露一个元数据层，显式定义：

  • 实体：“Customer”是一个具有特定字段和约束的数据模型（Data Model）。
  • 能力：“Approve Order”是一个具有定义好的输入和输出的离散服务函数（Service Function）。
  • 关系：“Order”属于“Customer”。

Loading...

当结构是显式的，AI 不需要阅读每一行代码来理解业务意图。它直接阅读“地图”。

JitAI 如何解决这个问题​

JitAI 通过 JAAP (JitAI Ai Application Protocol) 使应用结构机器可读，从而根本性地改变了开发范式。与那些将 AI 强行嫁接到现有代码库的平台不同，JitAI 围绕一个人和 AI 都能共享的结构定义来构建系统。

1. 应用结构作为一等公民​

在 JitAI 中，应用不仅仅是一堆文件；它是一个由 Meta（定义）、Type（模板）和 Instance（实例）构成的结构化对象图。

  • 自描述元素（Self-Describing Elements）：无论是数据模型还是服务函数，每个元素都有一个自描述的配置（例如 e.json）。AI Agent 不需要解析 Python 代码就知道一个函数的作用；它直接读取 functionList 中的结构化定义，其中包括精确的输入/输出规范和描述。
  • 语义可见性：因为结构是显式的，JitAI 的 AI Agent 可以“看见”整个应用拓扑。它们知道 CustomerModel 与 OrderModel 相关联，不是因为它们从变量名中猜出来的，而是因为元数据显式声明了这种关系。

2. Agent 作为系统参与者​

JitAI 不将 AI Agent 视为外部调用者，而是将其视为系统内部的参与者。

  • 直接操作：Agent 可以将服务函数（Service Functions）和模型函数（Model Functions）作为原生工具直接调用。无需专门为机器人构建单独的 API 层；系统内部的函数本身就是工具。
  • 全栈感知：通过解释型系统架构，Agent 可以感知并操作后端逻辑和前端 UI 组件，实现“人机 AI/UI 协同”，即 AI 可以在同一语境下起草 UI 表单或执行后端事务。

3. 结构化护栏​

JitAI 允许开发者直接在 Agent 工具上定义权限控制。你可以基于应用角色（Application Roles）限制 Agent 执行高风险函数（如 delete_database）的能力。这样，即使 AI 幻觉出了某种意图，结构化的护栏也会阻止未授权的执行。

实施手册：为 AI 构建结构​

即使你不使用像 JitAI 这样的专用平台，你也可以采用这些架构原则，让你的系统对 AI 更友好。

  1. 定义显式接口（"工具"模式）：

    • 不要让 AI 生成原始 SQL 或任意代码。
    • 将业务逻辑重构为离散的、原子的函数，并具有严格类型的输入和输出（例如使用 Pydantic 或 TypeScript 接口）。
    • 行动：创建一个 tools.json 清单，将业务意图映射到这些原子函数。

  2. 集中元数据：

    • 维护一个“系统地图”，以独立于代码的格式（如 OpenAPI 规范或自定义 JSON Schema）描述你的数据实体及其关系。
    • 行动：将此元数据动态投喂给 AI 的系统提示词（System Prompt），确保它始终知晓架构的当前状态。

  3. 实现“推理-行动”循环（ReAct）：

    • 从单次提示转向迭代循环，AI 在循环中规划行动、执行工具、观察输出，然后决定下一步。
    • 行动：使用支持状态管理的框架来跟踪对话历史和中间数据执行结果。

对比：AI 外挂 vs. AI 原生​

下表突出了围绕遗留代码“套壳”AI 与构建 AI 原生结构之间的操作差异。

特性AI 外挂 (传统)AI 原生 (如 JitAI)
可见性不透明 (代码即文本)透明 (结构即数据)
集成方式外部 API 调用系统内部参与者
维护成本高 (代码变更会导致 Prompt 失效)低 (自动与元数据同步)
上下文碎片化 / Token 受限整体性 / 架构级
可靠性易产生幻觉锚定于已定义的工具

如何验证​

要测试你当前的架构是否遭受“黑盒”困境，可以尝试以下方法：

  • “重命名测试”：重命名代码中的核心业务函数（例如将 calculateTax 改为 func_123）。如果你的 AI Agent 停止工作或无法理解工具的用途，说明它依赖的是表面的文本模式，而不是显式的结构定义。
  • “依赖性测试”：要求你的 AI Agent “删除一个用户”。它是否知道必须先检查是否存在活跃订单？一个定义了关系的 AI 原生系统会通过元数据或工具定义中的错误处理意识到这些约束；而外挂式系统可能只会试图强行执行删除。

常见问题 (FAQ)​

Q: “AI 原生”意味着我必须使用低代码平台吗？

A: 不一定。AI 原生指的是架构，而不是工具集。然而，像 JitAI 这样的平台通过强制执行 JAAP 协议为你处理结构定义，简化了这一过程，允许你在必要时使用全代码（Python/React），同时保持架构对 AI 可见。

Q: AI Agent 真的可以被信任处理业务逻辑吗？

A: 只有在受到约束的情况下才可以。Agent 不应该“猜测”业务逻辑。它们应该识别用户意图，然后调用执行该逻辑的确定性服务函数。AI 处理交互；代码处理事务。

Q: 这如何影响现有的开发工作流？

A: 这需要从编写命令式脚本转变为定义结构化元素。开发者花在编写样板代码上的时间减少，花在定义 AI 编排器将使用的能力（工具）和权限上的时间增加。

结语​

AI 仅作为简单聊天机器人覆盖层的时代正在结束。要构建能够利用 GenAI 全部力量的企业级软件架构，我们必须打破代码的黑盒。通过采用将应用结构视为一等公民的协议，我们将 AI 从一个困惑的局外人转变为一个能干的、深度集成的协作者。

准备好构建 AI 真正能读懂的系统了吗？