在企业级 IT 环境中，IBM 大型机仍然是许多金融机构、保险公司和政府系统的核心支柱。这些系统运行着数百万行 COBOL 代码，通过 3270 终端协议与操作人员进行交互。Hypercubic Hopper 作为新一代 AI Agent 接口，需要在看似过时的 TN3270 协议之上构建智能交互层 —— 将 LLM 的结构化决策转换为符合 3270 数据流规范的二进制编码，同时正确解析主机返回的屏幕数据。本文深入解析这一转换过程的技术细节，重点关注 screen buffer 布局、field attribute 编码以及 AID 命令结构。
TN3270 连接建立：从网络到终端会话
Hopper 与 z/OS 主机的连接建立在 TN3270 协议之上，这是传统 3270 终端协议在 TCP/IP 网络上的演进实现。当用户在 Hopper 中配置连接时，需要提供 TN3270 主机地址和端口号（默认 23），以及可选的 FTP 凭证用于数据集访问。这种双通道设计反映了一个重要事实：主机交互存在两种截然不同的数据平面 —— 实时终端会话平面和批量文件传输平面。
TN3270 会话建立后，终端仿真器与主机之间建立持续的连接状态。不同于现代请求 - 响应式的 REST API，TN3270 是一种半双工协议，采用 “发送 - 等待 - 响应” 的交互模式。AI Agent 无法主动推送数据到主机，而必须等待主机发送完整的屏幕刷新（通常是一个完整的 3270 数据流 Write 命令），然后才能决定下一步操作。当用户按下 Enter、功能键或执行字段修改时，终端会发送一个包含 AID（Attention Identifier）的入站数据流，主机应用程序根据 AID 类型和当前屏幕状态决定后续处理逻辑。
这种交互模式的本质限制了 AI Agent 的并发能力 —— 每个操作周期必须完整等待主机响应才能进行下一个操作。Hopper 的设计需要在保持这种同步交互语义的同时，将 LLM 的自然语言理解和决策能力映射到有限状态机的操作序列中。
3270 数据流结构：命令、属性与数据区域
3270 数据流是主机与终端之间通信的二进制协议，其结构远比表面看起来复杂。一个完整的数据流由多层嵌套的指令构成，包括命令码（Command）、命令属性（Attributes）、Orders（控制指令）和数据内容。理解这一结构是实现智能 Agent 的基础。
Write 命令是最常用的屏幕更新方式，其基本结构包含：命令码（0xF3 表示 Erase/Write，0xF5 表示 Write Structured Field）、操作数序列以及屏幕内容数据。每个命令后跟一系列 Orders，用于控制屏幕布局和属性设置。Set Buffer Address（SBA，0x11）是最常见的 Order，用于定位后续数据的写入位置；Set Attribute（SA，0x28）用于设置后续字段的属性；Repeat To Address（RA，0x3C）用于填充重复数据。
Field 属性的编码采用特殊的属性字节模式。在 3270 屏幕模型中，每个字段的第一个字符位置（起始位置）存储属性字节，该字节定义了字段的行为特征。属性字节的高位表示保护状态（0x20 表示非保护可输入，0x40 表示保护不可输入），低位表示显示属性（颜色、亮度、闪烁等）。例如，属性字节 0xC1 表示高强度非保护字段，0x60 表示标准强度非保护字段，0xF0 表示保护字段。AI Agent 在解析屏幕时需要跳过这些属性字节，提取实际的用户数据内容。
屏幕缓冲区的大小与字段数量直接相关。标准 3270 屏幕为 24 行 × 80 列，总计 1920 个显示位置。每个字段在缓冲区中占据从属性字节到下一个字段属性字节之间的连续位置。如果字段之间没有间隔，则前一个字段的最后一个数据字节实际上是下一个字段的属性字节。这种紧凑的编码方式要求 Agent 必须正确理解字段边界，否则解析出的数据将包含乱码。
AID 命令结构：用户动作的二进制编码
AID（Attention Identifier）是入站 3270 数据流的首字节，用于告知主机用户执行了何种操作。理解 AID 结构对于 AI Agent 至关重要，因为它是触发主机响应的唯一途径。Hopper 需要将 LLM 的决策（如 “按 F3 退出”、“在账号字段输入 12345 并按 Enter”）转换为符合协议规范的 AID 序列。
标准的 AID 值包括：0x7D 表示 Enter 键（最常用），0xF1 至 0xF9 表示 PF1 至 PF9 功能键，0x7B 表示 PF10，0x7C 表示 PF11，0x7E 表示 PF12，CLEAR 键的 AID 为 0x6F。不同的 AID 触发不同的应用程序分支逻辑 —— 同一个屏幕按 Enter 可能执行主流程，按 PF3 可能返回上一级菜单，按 PF1 可能显示帮助信息。
入站数据流的完整结构根据 AID 类型有所不同。对于简单的 Enter 操作，数据流格式为：AID 字节、2 字节的 cursor 地址（可选）、然后是所有修改过的字段数据。字段数据采用 “属性位置 + 数据” 的方式编码，Agent 仅发送被修改的字段内容而非整个屏幕，这被称为 Read Modified 模式。当使用 Write 操作时，主机在发送完 Write 命令后会等待用户输入，用户按 Enter 或功能键后的响应取决于应用程序的读模式 —— 可能是 Read Buffer（读取整个屏幕）或 Read Modified（仅读取修改过的字段）。
Hopper 在实现 AI Agent 时需要维护完整的屏幕状态模型，包括每个字段的位置、属性、当前值以及修改历史。当 LLM 决策需要修改某个字段时，Agent 必须在出站数据流中包含该字段从属性字节位置开始的完整数据（包括属性字节本身后跟实际输入内容）。如果遗漏属性字节或位置偏移错误，主机将无法正确解析数据，导致输入错误或屏幕异常。
Screen Buffer 解析：构建可操作的屏幕状态模型
AI Agent 与 3270 终端交互的核心能力之一是正确解析主机返回的屏幕数据流，将其转换为 Agent 可理解的屏幕状态模型。这个过程涉及将二进制数据流解码为结构化的字段集合，同时处理属性字节、订单序列和编码数据。
解析过程的第一步是识别数据流中的 Orders 和数据区域。当收到一个 Erase/Write 命令后，Agent 需要按照 Orders 序列逐步构建屏幕图像。SBA Order 告诉 Agent 下一个数据写入的缓冲区地址；RA Order 表示从当前地址到目标地址之间的所有字节都填充为指定字符；EA（Erase Unprotected to Address）清除指定范围内的未保护字段内容。Agent 必须按顺序处理这些 Orders，正确维护当前写入位置指针。
第二步是识别字段边界并提取字段值。在数据流中，每个字段的起始位置是属性字节，后续位置是该字段的数据内容。当遇到下一个属性字节（通常在数据流中表现为特定的 X'00' 到 X'3F' 范围字节，因为属性字节的高位模式）时，表示当前字段结束。Agent 需要根据属性字节确定字段类型（非保护输入字段、保护显示字段等），然后提取属性字节之后到下一个属性字节之前的数据内容作为字段值。
一个典型的屏幕解析结果可能如下：字段 1（位置 0-80）账号字段，非保护，值 "1234567890"；字段 2（位置 81-200）姓名字段，保护显示，值 "张三"；等等。Hopper 的 Agent 需要维护这个屏幕状态模型，并在每次主机响应后更新它。当用户（或 AI Agent）修改某个字段并发送响应时，只有该字段的数据会被包含在入站数据流中。Agent 必须知道该字段在屏幕缓冲区中的精确位置，以便正确编码修改后的数据。
对于包含重复区域的屏幕（如列表展示），情况更为复杂。每个列表项可能占据固定的行数，属性字节的排列方式决定了如何识别每个项的边界。Agent 可能需要理解特定的屏幕布局约定（如第一列为行号显示，第二列为数据列），才能正确解析列表数据并支持增量操作。
从 LLM 决策到二进制编码：Hopper 的转换层
Hopper 的核心价值在于将 LLM 的自然语言理解能力和决策能力转换为符合 3270 协议规范的操作序列。这一转换层需要解决两个关键问题：决策解释和协议编码。
当 LLM 表示 “将账号字段修改为 123456 并按 Enter” 时，Hopper 需要将这个意图分解为具体的协议操作。首先，Hopper 需要查询当前的屏幕状态模型，确定 “账号字段” 在屏幕上的位置（行号、列号）和属性（是否可输入、长度限制等）。然后，Hopper 需要将新值 "123456" 编码为符合字段定义的字节序列 —— 对于标准 EBCDIC 编码的字段，这意味着将 ASCII 字符串转换为 EBCDIC 编码的字节流。
出站数据流的构造需要严格遵循协议格式。假设账号字段起始于屏幕位置 row=6, col=20，对应的缓冲区地址需要通过行列计算转换为 3270 内部地址格式（双字节，高位在前）。Hopper 需要构造一个 Read Modified 命令（命令码 0x31），后跟修改过的字段数据。字段数据的格式是：属性字节（原字段属性）后跟新的数据内容。发送顺序必须是从低地址到高地址，符合 3270 协议的线性寻址模式。
Hopper 还必须处理边界情况和错误恢复。当 LLM 尝试输入超过字段最大长度的数据时，Agent 应该拒绝操作并提示用户，而非尝试截断输入。当主机响应表明输入错误（如字段验证失败、屏幕异常）时，Agent 需要解析错误信息并将其呈现给 LLM，以便 LLM 可以调整策略重新尝试。这种反馈循环是实现可靠自动化的关键。
实践中的技术考量与限制
在实际部署中，基于 TN3270 的 AI Agent 面临诸多技术限制。协议本身的半双工特性意味着 Agent 无法实现真正的并发操作 —— 每次操作必须串行等待主机响应。对于需要执行多步骤事务的场景（如填写表单的多个字段），这可能导致较长的总执行时间。优化策略包括批量准备所有修改（当 LLM 需要修改多个字段时），然后一次性发送，而非逐字段交互。
屏幕状态同步是另一个关键挑战。在 Agent 处理主机响应并生成下一步决策的期间，如果主机端有其他操作（如批量作业完成通知、定时消息），屏幕状态可能发生变化。Agent 需要实现屏幕状态变更检测机制，在每次操作前重新检查屏幕内容，确保决策基于最新状态而非过期信息。
数据编码的正确性直接影响交互的成功率。EBCDIC 与 ASCII 的转换必须精确，因为一个错误的字节可能导致整个字段值被主机拒绝或错误解析。某些字段可能有特殊的格式要求（如前导零、数字右对齐），Agent 需要理解这些格式约定并在编码时遵循。Hopper 的实现通常包含针对常见字段类型的编码器，支持自动格式化而无需 LLM 显式指定。
安全考量也不容忽视。TN3270 连接本身不加密（除非使用 TN3270E 并启用 TLS），在生产环境中需要确保网络路径的安全。Agent 操作需要与主机的访问控制机制（如 RACF）集成，确保 AI 的操作权限不超过连接用户的授权范围。对于敏感操作（如修改生产数据），应实现人工审批机制，而非完全自动化执行。
Hopper 将 AI Agent 的自然语言决策转换为 3270 二进制数据流的过程，本质上是在现代概率推理引擎与上世纪七十年代的确定性协议之间架设桥梁。这个转换层需要精确理解 TN3270 协议的二进制结构、屏幕缓冲区布局、字段属性编码以及 AID 命令语义。尽管协议本身复杂且缺乏现代 API 的便利性，但它确保了与数十年积累的大型机应用程序的兼容性，这正是 Hopper 能够在企业环境中落地的技术基础。
资料来源：Hopper 文档（docs.hypercubic.ai/quickstart）、IBM 3270 Data Stream Programmer's Reference（GA23-0059）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。