这篇解决什么困惑

做 Agent 是否应该直接用 Python？这是我从 Java 后端转向 Agent 开发时反复遇到的问题。Python 的模型与数据生态更丰富，示例也更多；Java 已经承载认证、数据库和业务服务。如果只靠偏好争论，很容易在“生态先进”与“已有资产”之间来回摇摆。

所以我没有直接选语言，而是做了同一协议下的两个可执行切片：进程内 Java DecisionEngine，以及由 Java 控制面启动的一次一进程 Python Worker。比较的不只是速度，还包括语义结果、故障隔离、镜像、秘密边界和部署成本。

关键结论

当前选择进程内 Java 作为默认 Agent 执行路径，Python Worker 保留为可选实验边界。这个结论不是“Java 比 Python 更适合 AI”，而是：在当前证据任务和单机部署条件下，Python 没有带来语义质量收益，却增加了协议、进程生命周期和运维故障面。

更重要的是，Python Worker 不是未来待画的框，它已经有最小参考实现和故障测试；但它不在默认生产拓扑中，也没有被当前应用主路径调用。不能把“存在实验代码”写成“系统已采用 Python Worker”。

实验怎样保持可比

两个实现共享版本化的 DecisionEngine 契约，只收到问题、步骤、已观察 Claim ID 和剩余预算。Java 始终拥有运行状态、工具执行、数据库、秘密、预算和最终校验。Python Worker 使用一问一答的 JSON Lines 子进程协议，不接收数据库连接、API Key、文档正文或 Evidence quote。

这种设计故意让决策策略保持一致，先回答运行时边界问题，而不是同时比较语言、框架和模型。固定集包含支持、反对、证据不足、类似提示词注入和无关干扰五类。每个运行时进行一次冷调用和多轮 warm decision，并注入超时、进程崩溃、非法输出和超大输出等故障。

实验真正说明了什么

两种确定性实现都只在五类中的两类做对，语义成功为 40%，false completion 为 60%。它们犯相同错误：只要检索到 Claim 就当成支持。这个结果证明策略没有达到质量门，不能证明哪门语言更聪明。

运行边界的差异则很明确。进程内 Java 调用几乎没有额外边界成本；当前 Python 设计每次启动新进程，单次带来约百毫秒量级开销。Python Worker 自身的镜像和空闲内存更小，但对比对象并不等价：Java 数字来自完整 Spring 应用，Python 数字来自微型 Worker。它们只能说明部署量级，不能作为纯语言基准。

四类注入故障都被 Java 适配器分类并隔离，一次非法完成也能被 Completion Verifier 拒绝后恢复。这证明 Worker 边界可行，同时也把新增成本暴露出来：序列化、超时、stdout 限制、stderr 脱敏、子进程退出码、第二镜像和双语言测试都需要维护。

为什么当前选 Java

已有应用的认证、事务、证据检索、模型网关、测试和部署都在 Java。把默认决策放在进程内，可以复用同一类型系统与可观测链路，不需要为了一个尚无质量收益的组件增加第二运行时。

Java 仍然掌握 Observe、Act、Verify、Recover 和 Stop。即使未来引入 Python，Worker 也只应在窄协议后负责确有价值的计算，不能获得数据库、秘密或任意工具权限。这样引入的是能力，不是第二个控制面。

对应代码与测试证据

逻辑模块包括统一 DecisionEngine 协议、进程内 Java 实现、Python Worker 适配器、参考 Worker 脚本、协议一致性测试、运行时基准和故障隔离测试。架构决策记录明确了默认拓扑为 Java 应用加 PostgreSQL，Python 镜像仅是可选开发资产。

后续 stance-aware 的真实模型决策也首先落在进程内 Java 适配器中，因为它需要受权限保护地解析已观察证据。Python 协议仍只携带 ID，没有为了追求“Python 化”而扩大跨进程信任边界。

真实踩坑

第一个坑是比较不等价指标。完整 Java 服务与空闲 Python 脚本的内存、镜像不能直接得出语言效率结论。第二个坑是把输出一致误认为质量一致：两个实现都输出同样结果，可能只是一起答错。

第三个坑是把隔离当成免费安全。子进程确实能限制崩溃影响，但协议解析、超时和日志同样可能泄漏或失控，必须通过故障注入证明。第四个坑是认为“Agent 流行 Python”本身就是迁移理由。生态趋势值得关注，却不是当前系统增加运行时的验收证据。

何时重新引入 Python

架构决策给出的重评条件很具体：出现 Java 难以实现而 Python 已证明可行的关键能力；同语料实验显示明显质量或交付收益；真实模型延迟已经占主导且持久 Worker 能满足运维预算；Python 专属实验工具增长到维护 Java 等价物更贵；或者系统本来就需要独立 RPC 执行面。

重评时仍要重复 Schema、秘密隔离、故障注入、镜像与运维、语义质量测试。不能只比较一段 happy-path Demo。

当前与未来

当前 Python Worker 已存在于实验与回归层，不是默认服务依赖。默认路径继续使用 Java，并优先补齐 M3 的 checkpoint、trace、真实预算和工具恢复。未来若 M4 的隔离实验执行大量依赖 Python 数据科学库，Worker 很可能变得有价值；但那需要新的可执行证据，而不是提前宣布。

更新时间：2026-08-18