AI答卷落地：旧基建如何成为智能体时代的运行底座

当模型不再只是“回答问题”，而是要真正“动手做事”时，整个技术栈的注意力正发生一次静默的转移。过去几年，行业的聚光灯始终打在参数规模、上下文长度和推理能力上；而如今，越来越多的工程实践开始回归到那些看似“过时”的基础设施：HTML、JavaScript、浏览器、iframe、文件系统、终端、权限、沙盒与状态机。

这并非技术倒退，而是一场深刻的工程收敛。AI 从“生成答案”到“执行动作”的跃迁，迫使非确定性的模型必须重新接入现实世界中最稳定、最成熟、最经得起摔打的软件结构。理解这一转向，是构建可靠智能体应用的前提。

一、从“生成”到“行动”：问题域的根本位移

早期的 AI 应用给人一种错觉：模型会吞掉一切。Prompt 可以解决所有问题，长上下文可以覆盖所有信息，多智能体协作可以自动分解所有任务。在这种叙事下，外部工程结构似乎注定要退居幕后，甚至被彻底取代。

但当 AI 真正开始读写文件、修改代码、控制浏览器、调用工具、执行终端命令、影响业务流程时，问题立刻变了。我们不再只关心模型“能不能生成正确答案”，而必须回答一系列更棘手的问题：

• 它如何获取执行权限？权限边界在哪里？
• 它执行的动作是否可追溯、可审计？
• 如果执行出错，如何回滚到安全状态？
• 在关键节点，人类如何重新接管？
• 多个并发动作之间如何避免状态冲突？

这些问题已经超出了模型能力的范畴，进入了系统工程领域。模型依然重要，它是决策的发动机；但发动机需要底盘、传动轴、刹车系统和仪表盘，才能安全上路。这正是浏览器、文件系统、终端、Git、沙盒这些“旧东西”重新登台的原因。

二、为什么是“旧基建”？——工程收敛的必然逻辑

非确定性系统进入现实世界，面临的最核心挑战是“不可控”。模型输出天然具有概率性，同样的输入可能产生不同的结果。而现实世界的执行环境要求确定性：文件要么写入成功，要么写入失败；进程要么启动，要么退出；权限要么授予，要么拒绝。

这种矛盾决定了 AI 不能直接裸奔在操作系统或业务系统之上。它需要一层“中间层”来消解不确定性，而这层中间层恰恰是软件工程几十年沉淀下来的成熟结构。

1. 浏览器与 HTML：作为“通用环境”的交互层

当 AI 需要与用户进行复杂交互时，纯文本的 Markdown 已经不够用了。表单校验、拖拽上传、分步确认、实时状态展示——这些都需要成熟的 UI 基础设施。HTML 和 JavaScript 经过三十年发展，拥有最完整的组件生态、无障碍支持和跨平台能力。

更重要的是，浏览器本身就是一个天然的沙盒环境。iframe 提供了进程级隔离，Canvas 和 WebGL 提供了图形渲染能力，Web Worker 提供了并行计算通道。AI 驱动的交互界面选择 HTML，不是因为“传统”，而是因为它是唯一一个既成熟又具备安全边界的通用交互层。

2. 文件系统与 Git：状态管理的基石

AI 执行任务必然产生状态：中间产物、配置文件、日志、缓存、输出结果。如果这些状态散落在内存中，一旦进程崩溃或模型上下文被截断，整个任务就会断点失效。文件系统提供了持久化存储，而 Git 则在此基础上提供了版本控制和回滚能力。

试想一个 AI 修改代码的场景：它读取了仓库，在多个文件中进行了修改。如果没有版本控制，任何一步出错都可能导致整个仓库的不可逆损坏。但有了 Git，AI 的每一次修改都可以是一个 commit，人类可以逐条审查 diff，随时 checkout 回任意历史版本。这种“可回滚”的能力，是 AI 从演示走向生产的关键基础设施。

3. 终端与权限：从“建议”到“授权”的关口

终端是现代操作系统中最强大的接口，也是风险最高的接口。当 AI 需要执行命令时，本质上是将系统控制权的一部分委托给了一个非确定性程序。因此，权限管理和沙盒机制变成了安全底线。

一个合理的架构是：AI 提出要执行的命令，但命令首先进入一个审批队列，由人类确认后才能放行。在执行层，沙盒限制了文件系统的可访问范围、网络连接的允许列表、进程的 CPU/内存配额。终端不再是“裸奔的 Shell”，而是“带围栏的操场”。

4. 状态机：将非确定性的流程拉回确定性的轨道

AI 驱动的业务逻辑往往具有分支判断和循环迭代，但这些流程不能是“自由发挥”的。状态机提供了一种显式定义状态、事件和迁移规则的建模方式。它将 AI 的行为限制在一个预定义的框架内：每个状态下，只有合法的输入事件才能触发迁移，非法操作直接被拒绝。

例如，一个 AI 驱动的自动化测试工具，其状态可以定义为“待执行”、“运行中”、“等待确认”、“失败重试”、“已完成”。AI 只能在这些状态间按照预定义的规则迁移，而无法凭空跳转到一个未定义的状态。这大大降低了系统出错的概率，也让问题定位变得简单。

agent-">三、重新组织：Agent 时代的基础设施栈

这些“旧基建”并非简单地重新启用，而是需要被重新组织成一套面向 Agent 的基础设施。这套基础设施至少包含以下层次：

执行层：提供受限的运行环境，包括沙盒进程、容器、虚拟化技术。AI 的代码和命令在这个层运行，但无法触及宿主机的敏感资源。

状态层：负责持久化和同步 Agent 的工作状态。文件系统存数据，Git 存版本，对象存储存大文件，消息队列存事件流。

交互层：负责连接 Agent 与人类，既包括 Web 前端（HTML/JavaScript），也包括终端输出、通知中心、审批面板。

治理层：负责权限管理、审计日志、监控告警、成本控制。每一步 AI 动作都要留痕，每一项资源消耗都要计量。

接口层：负责将 Agent 连接到外部系统，包括数据库访问、第三方 API、内部微服务。这一层通常通过标准化的协议（如 REST、WebSocket、消息队列）实现解耦。

四、一个可落地的架构参考

为了帮助理解，以下是一个示意性的架构伪代码，展示如何将 AI 引擎嵌入到受控的执行环境中：

# 伪代码：Agent 执行框架的核心抽象
class AgentRuntime:
    def __init__(self, workspace, sandbox, state_machine):
        self.workspace = workspace  # 文件系统工作区
        self.sandbox = sandbox      # 沙盒隔离层
        self.state_machine = state_machine  # 状态机控制器
        self.history = GitHistory() # 版本控制
    def execute(self, task_plan: str):
        # 1. 检查当前状态是否允许执行
        if not self.state_machine.can_transition("running"):
            raise PermissionError("当前状态不允许执行新任务")
        # 2. 在沙盒中创建隔离环境
        with self.sandbox.create_session() as session:
            # 3. 执行 AI 生成的命令序列
            for cmd in self.plan_to_commands(task_plan):
                # 4. 每个命令先进入审批队列
                approval = self.request_human_approval(cmd)
                if not approval:
                    self.state_machine.transition("awaiting_approval")
                    return
                # 5. 执行命令并记录到 Git
                output = session.run(cmd)
                self.history.commit(f"Executed: {cmd}")
        # 6. 状态迁移
        self.state_machine.transition("completed")

在这个示意中，AI 不再是直接接触操作系统的进程，而是通过四层保护（状态机约束、沙盒隔离、人工审批、版本控制）来执行任务。每一层都在“消解不可控性”，从而将模型的非确定性转化为业务可接受的确定性。

五、未来：AI 没有绕开旧世界，它正在借助旧世界进入现实

回看当前的技术趋势——智能编程工具需要 Git 才能安全地修改代码；桌面级 AI 助手需要沙盒和权限控制才能操作文件；企业级 Agent 需要审批流和审计日志才能接触核心业务系统——我们会发现，所有看似“创新”的 AI 产品，底层都押注在那些已经存在了几十年的工程结构上。

这给出一个重要的启示：AI 落地的瓶颈，从来不只是模型能力，更是工程整合能力。谁能把状态机、权限、沙盒、版本控制这些“旧要素”以最优雅的方式组合起来，谁就能为 AI 提供最坚实的进入现实的形状。

模型是发动机，但汽车不能只有发动机。底盘、刹车、仪表盘、导航系统——这些“不性感”的部分，恰恰决定了 AI 能跑多远、跑多稳。对于开发者来说，理解并掌握这套“旧基建”的重新组织方法，比追逐下一个模型参数突破更具长期价值。