为什么 TeaQL 开发了 7 种语言的 Runtime
AI 写代码越来越快，软件工程的难题却没有随之消失。
项目早期，Agent 面对少量文件，往往进展顺利。到了中后期，源码、历史约定和工具输出不断增加，上下文越来越长，可能出现反复修改、不断消耗 token，却难以取得进展的情况。
与此同时，生成的代码还要长期维护。租户隔离、事务、隐私和审计等规则，需要在查询、保存和异常路径中持续生效；系统上线后，团队也需要知道问题发生在哪里。
我们的思路是：压缩 AI 必须生成和理解的范围，把共同的工程规则放进稳定的抽象层。Runtime，就是这个抽象层在真实运行中的执行者。
少生成代码，需要一层可复用的抽象
TeaQL 把开发过程分成三个阶段：
- 建模及评估：AI 生成和修订领域模型，通过检查后得到一个 XML。
- 语义生成：确定性工具生成 Type Library、文档和初始 Workspace，并引入对应 Runtime。
- 深度定制：AI 与工程师在 Workspace 中完成项目特有的业务。
AI 主要处理领域模型和业务定制。Type Library 由生成器产生，Runtime 被直接复用，Agent 无需为每个项目重新实现查询、事务、追踪和隐私基础设施。
通用 Coding Agent 提高通用任务能力的上限；TeaQL 希望通过领域建模与可复用的工程基础，提高团队能够开发和维护的软件规模上限。这对上下文与算力有限的本地、边缘环境尤其有价值。
AI 写得越多，运行时的兜底越重要
代码能够编译、通过已有测试，仍可能遗漏权限边界、并发冲突或异常路径。测试覆盖预先设计的场景，Runtime 则在每一次真实请求中执行已配置的规则。
当代码越来越多由 AI 编写，Runtime 是进入生产后最后一道持续工作的工程防线。
我们把几类公共能力放在这一层：
- 可观测、可跟踪、可调试：保留业务意图、执行路径、日志与 SQL，让 Debug Assist 和开发者有依据地定位问题。
- 可集成、可定制：通过明确的扩展点连接数据库、身份系统与已有服务，并安装客户自己的业务策略。
- 可汇总、同步执行隐私策略：让多语言组件的运行证据具有共同语义，让日志、追踪和诊断按模型策略处理敏感信息。
Runtime 无法保证软件没有 Bug，但可以持续执行明确的约束，并在失败时留下证据，减少在生产环境临时猜测和调试的需要。
一个例子：把租户隔离放到执行边界
假设一个订单系统同时服务租户 A 和 B。如果每个页面都自行添加 tenant_id 条件，列表可能写对了，关联加载、聚合或新生成的接口却可能遗漏。
TeaQL 允许应用在 Runtime 的扩展点安装租户规则：
认证后，把可信租户写入 UserContext
→ 查询策略约束查询、关联和聚合范围
→ 初始化新对象时写入可信租户
→ 变更策略检查待保存的数据
→ 数据库操作执行租户条件
Workspace 中的业务代码继续表达“加载待审核订单”。共享表模式下，更新操作可以形成下面的执行边界（示意）：
UPDATE customer_order_data
SET status = :nextStatus, version = version + 1
WHERE id = :id
AND tenant_id = :trustedTenant
AND version = :expectedVersion;
对象 ID、租户和版本条件在同一次更新中检查，避免把“先检查归属、再修改数据”拆成容易发生竞争的两步。客户采用独立数据库时，也可以根据可信 Context 路由到对应租户的连接。
关键是：租户身份来自服务端认证，不能由请求中的普通字段自行指定。 客户仍需定义租户语义、安装策略，并让缺少可信租户的操作被拒绝。
这类边界已有具体执行记录：2026 年 9 月的 Go 与 .NET 安全示例验证了拒绝不可信控制字段、服务端注入查询范围，以及更新、删除和恢复时同时检查租户、ID 与版本。这里的证据限定于这两种实现的对应示例。
关键证据：能看到执行，也能看到错误被拦住
一次订单查询，可以追到实际 SQL
下面是 TypeScript + SQLite 订单示例接入 OpenObserve 的截图。一次“展示订单列表”的请求展开为分页、计数、关联加载与聚合，对应 8 次实际 SQL 执行。
图：业务 TraceChain 与实际 SQL 的关联。展开 SQL 节点可查看脱敏 SQL、追踪标识、耗时和返回行数。
标准遥测是一项开箱即用的能力。 按 Workspace 指引启用模块、配置采集端并导入配套面板后，Runtime 负责采集和关联执行信息，无需为每条查询重复编写采集逻辑。七种 Runtime 的内部安装包也在 2026 年 10 月完成了两轮标准遥测接入检查。
Java 订单示例的日志中，同样能看到业务意图和隐私处理。以下仅摘取关键字段：
purpose=Show the operator a deterministic order list
comment=List WEB orders for the terminal quick start
-- NOT REPLAYABLE; masked_parameters=1
WHERE ... order_number LIKE '[REDACTED]' /* masked */
开发者能理解为什么读取订单，同时不必在诊断输出中暴露订单号原值。
失败路径也留下可检查的结果
Rust 订单示例保留了三类关键结果：
| 操作 | 运行结果 |
|---|---|
| 订单行缺少 SKU | 校验指出 Order_line_list[0].Sku 必填 |
| 使用过期版本更新 | 返回 OptimisticLockConflict |
| 取消包含新建子对象的操作 | database_rows=0，没有残留该次新增记录 |
这些结果展示了校验、并发保护和回滚的实际作用。上层代码发起操作后，Runtime 中已经安装的规则仍会执行。
同一模型，在七种语言中实际运行
我们用 Order 和 School 两个模型生成七种语言的 Type Library，再连接各自 Runtime 与 SQLite，分别运行两轮，检查查询、分页、聚合、关联和保存行为。七种 Runtime 的完整原生示例，以及七语言 Debug Assist 生成代码的编译与 SQLite 执行，也有通过记录。
验证曾发现 Rust 对反向聚合别名处理的缺口，修复后才重新运行。这正是内部一致性验证体系 Conformance 的作用：发现并复现不同实现之间的语义偏差。这组结果限于当时的本地实现与 SQLite，其他数据库和环境需分别验证。
为什么需要七种语言？因为软件要进入不同生态
抽象层要真正减少项目代码，就必须接入团队已有的框架、工具链、部署方式和人才生态。
| Runtime | 适合发挥生态优势的场景 |
|---|---|
| Java | 企业核心系统、复杂业务与长期演进的后端 |
| Rust | 支付核心链路、金融交易、撮合、实时行情与低延迟服务 |
| TypeScript | Web 交互、全栈应用与前后端共享类型 |
| Swift | iOS、macOS 与 Apple 端侧应用 |
| Python | AI、数据分析、科学计算与自动化 |
| .NET | 制造、能源、交通、MES、设备管理及 Microsoft 生态 |
| Go | 云基础设施、网络服务、微服务与运维工具 |
一个项目通常会组合多个 Runtime，例如 TypeScript 前端、Java 后端和 Python 数据管线。它们使用原生生态完成交付，同时共享领域语义和工程约束。
第八个 C++ Runtime 也正在支持中，面向工业设备、边缘计算、嵌入式和既有 C++ 工程。目前仍在开发与验证阶段。
七种 Runtime 的投入，最终是为了让每个项目少写、少读、少维护重复代码，让 AI 集中处理业务差异，让明确的工程规则持续作用于开发和生产。
在浏览器里亲自试一下
TeaQL Browser SQLite Playground 可以直接在线体验。TypeScript Runtime 与 SQLite/WASM 在浏览器中运行。
打开 Order Center，尝试搜索、分页和状态分组，再查看对应的 TraceChain 与 SQL，就能把一次页面操作与实际执行联系起来。这个 Demo 展示浏览器运行时；服务端租户隔离需在可信服务端落实。
也可以通过 TeaQL Agent Kit 免费体验 Harness。
证据说明：文中日志、截图与验证结果来自固定版本的内部工程记录，相关仓库和原始文件尚未公开。文中只展示关键节选，不作为性能比较或所有语言、数据库与部署组合均已验证的声明。
