#GOAI大赛 #Agent Infra #Datawhale一个“纯血 Java”开发者的 GOAI Agent Infra 比赛复盘从 7000 行 Java 后端、25 张数据库表到一条 6 分 39 秒可以稳定讲完的多智能体闭环。这是我第一次参加 AI 相关比赛也是第一次真正动手开发智能体。在这之前我长期做 Java对 Spring、数据库、状态机、事务这些东西更熟悉。刚开始做智能体项目时我下意识地把过去最擅长的东西搬了过来先设计一个足够完整的后端再考虑 Agent 怎么接进去。结果是我前后做了三个版本。1.0后端很扎实但比赛重心偏了2.0把自由交给 AI又从“工程完整”走向了“系统失控”3.0终于学会先设计演示再决定系统里应该有什么。现在回头看这次比赛最大的收获不是学会了某个 Agent 框架也不是把 Java 换成了 Python而是重新理解了一件事智能体项目不是给传统系统外挂一个聊天入口它首先要回答“为什么这件事必须由多个 Agent 协作完成”。项目代码和完整设计文档已经放在 GitHubRicoPing11/judgeflow。一、最初的题目让裁决过程可以被审查我的项目叫 JudgeFlow选择的是内容治理中的争议案件裁决。我想展示的不是“AI 自动处罚用户”而是一个更克制的闭环调查取证 → 风险研判与反证审查 → 独立裁决 申诉改判 → 问题归因 → 规则草案 → 案件回放 → 人工审批这里有几个从一开始就没有改变的边界Agent 不直接写数据库也不直接推进业务状态Agent 的输出必须是结构化产物由后端验收工具调用失败不能被解释成“没有查到数据”回放指标由确定性 Python 代码计算而不是让大模型自己报分Human APPROVE 只记录比赛环境中的审批不等于发布生产规则Demo 不执行真实处罚也不接触真实用户数据。JudgeFlow 到底是一个什么项目JudgeFlow 是一个面向高风险内容治理的多智能体调查、裁决、申诉与规则演进系统。它要解决的不是“让大模型代替人处罚用户”而是当一个案件需要 AI 参与时怎样避免同一个模型既调查、又起诉、又替自己辩护最后还批准自己的结论。为此我把一件看似连续的任务拆成了互相制约的角色调查 Agent 从授权材料中提取可观察事实、推断和缺失信息风险 Agent 站在风险侧形成意见反证 Agent 独立寻找反例、例外和证据缺口裁决 Agent 同时审查正反意见形成结构化裁决申诉 Agent 基于冻结原案和新增证据独立重审归因 Agent 判断问题来自规则、证据还是执行过程只有规则缺口才会触发规则起草和确定性历史回放最终候选规则交给 Human 审批Agent 无权自行发布。项目页面不只是展示几段 Agent 对话而是可以查看案件、规则版本、WorkOrder、Artifact、正反意见、申诉改判、规则 Diff、逐案回放结果以及人工审批记录。每一份正式结论都能追溯到对应的任务、输入引用、运行编号和内容哈希。换句话说JudgeFlow 想证明的是多 Agent 的价值不仅是分工提效也可以通过职责隔离、信息隔离和确定性验收让 AI 参与的高风险决策更容易被复核。我从零学习的技术栈这套技术栈对长期做 Java 的我来说绝大部分都是这次比赛才真正上手层次技术在项目中的用途语言与工程Python 3.12、uv业务内核、依赖管理和运行环境数据契约Pydantic 2、JSON Schema定义 WorkOrder 和九类正式 Artifact拒绝不合法模型输出数据库PostgreSQL、SQLAlchemy 2、Alembic保存案件状态、不可变产物、规则版本、回放和审计事件Agent 工具协议MCP / FastMCP向 Agent 暴露 5 个最小工具不开放数据库写入能力多 Agent 协作AgentTeams、MatrixManager、Team Leader 和领域 Agent 的组织、路由与按需唤醒接入与隔离Higress、DockerMCP 接入、身份边界和本地可重复运行环境确定性计算Python 自研规则执行器执行新旧规则并计算逐案回放指标不让 LLM 自己打分前端原生 HTML、CSS、JavaScript构建比赛单页 Demo展示真实后端投影没有再引入前端框架测试pytest验证 Schema、状态机、权限、幂等、失败语义和完整闭环我刻意没有引入 LangChain、LangGraph、RAG、向量数据库或新的微服务。不是这些技术没有价值而是当前固定 Demo 不需要它们。对于第一次做 Agent 项目的人来说能清楚解释每一个组件为什么存在比堆出一张很热闹的技术栈图更重要。在线链路验证阶段使用 AgentTeams v1.2.0 组织资源通过 Matrix 路由任务并让领域 Worker 经 Higress 调用 FastMCP。AgentTeams 负责“谁在什么时候工作”JudgeFlow 后端负责“什么结果才算正式结果”。两者之间的边界也是这个项目最重要的设计之一。听起来已经很明确但真正开始开发后我还是连续走了两次弯路。二、1.0一个很像平台、却不像 Agent 作品的项目1.0 版本叫 PolicyOps。这是我最熟悉的开发方式Spring Boot、MySQL、React先做通用 Kernel、Policy IR、确定性规则运行时再做 Content Safety 和 Procurement Approval 两个 Domain Adapter。最终这个版本有 72 个 Java 文件Java 代码约 7000 行即使经过一轮主动精简后端仍然有 61 个生产 Java 文件、9 张业务表、6 个策略状态。它能完成危险策略拦截、回放、人工准入、发布后复验和回滚53 项后端测试也全部通过。从传统工程的角度看它并不差甚至相当完整。但它有一个致命问题Agent 不是主角。当时 AgentTeams 还没有真正接入业务闭环系统里只有一个默认关闭的 Agent Gateway。最完整、最可靠、最花时间的部分全是我熟悉的后端能力。评委真正关心的多 Agent 分工、协作过程和不可替代性反而停留在文档和待办列表里。我还试图同时证明两个业务领域复用同一个内核。这个目标放在产品长期建设里很合理但放进 5—8 分钟的比赛演示就意味着我要先解释 Policy IR、Domain Adapter、生命周期、准入、发布、回滚再解释 Agent 到底做了什么。观众很可能先看到一个规则治理平台然后才在角落里发现它“也支持 Agent”。1.0 给我的第一个教训是技术上最完整的部分不一定是比赛里最有价值的部分。我当时是在用自己最熟悉的能力回避最陌生的问题。后端做得越完整我越有安全感但作品也离“Agent Infra”越来越远。三、2.0让 AI 放手设计复杂度很快失控意识到 1.0 的问题后我把技术栈切到 Python希望更贴近 Agent 生态也给 AI 更高的设计和实现自由度。这一次Agent 确实被放到了中心。系统设计出了 Manager、两个 Team Leader 和八个领域 Agent有 WorkOrder、Artifact、规则快照、申诉白名单、产物谱系、回放数据集、工具审计和完整状态机。然后另一种问题出现了。设计文档中的核心持久化模型一路增长到 23 张表实际 SQLAlchemy 模型最终是 25 张表包括原案快照、规则快照和快照明细Agent Run、Tool Call、Artifact、Artifact Link、Artifact Selection演进信号、信号案件、规则草案修订链回放数据集、数据集案例、回放任务、逐案结果文件对象、审批记录等。每一个对象单独看都有理由每一层也都“更严谨”。但它们组合起来后已经远远超过了一个比赛 Demo 的解释能力和维护能力。除此之外我还为运行环境增加了安装、同步、清理、回滚、镜像构建、Higress 检查以及各种 guard 脚本。很多工作都在解决“如何让这套复杂系统安全、稳定地运行”而不是在增强主 Demo 的表达。这里最值得反思的不是“AI 写了太多代码”而是我没有给 AI 一个足够窄的优化目标。如果目标只是“设计得完整、可扩展、可审计”AI 会非常认真地补齐所有可能缺失的组件。它不会天然知道这个项目只有一个人维护比赛演示只有几分钟评委不可能跟着我读完 25 张表的 ER 图。所以 2.0 的问题本质上不是 AI 自由度太高而是我把架构决策权交给了 AI却没有先把比赛的时间预算、叙事预算和复杂度预算写成硬约束。这也是我对“人机协作”认识变化最大的一点。AI 很适合扩展方案、补齐边界、并行实现和审查但“这个作品到底要证明什么”“五分钟后评委应该记住什么”必须由人负责。四、3.0先写演示剧本再写 Schema3.0 没有从“还能删掉哪些表”开始而是从一个更直接的问题开始如果只有 5—8 分钟我要让评委看到哪两个闭环答案被固定为首次裁决调查 → 正反独立研判 → 裁决 后续演进申诉改判 → 归因 → 规则草案 → 回放 → 人工审批然后我反过来约束实现任何 Agent、房间、表、MCP 工具、Skill 或服务如果不能证明主 Demo 没有它就无法完成就不增加。3.0 最终收敛为项目最终规模PostgreSQL 业务表8 张MCP 工具5 个自研 Skill4 个领域 Agent8 个协调 Agent3 个Human 角色1 个自动化测试143 项实际演示时长6 分 39 秒这里的 Agent 资源并不是为了“数量多”。真正负责业务判断的是八个领域 Agent调查、风险研判、反证审查、独立裁决、申诉复核、问题归因、规则起草和回放分析。Manager 和两个 Leader 只负责路由不生成正式业务结论。它们也不是全部常驻。平时只保留 Manager其他 Worker 按阶段唤醒主流程峰值并发只有 Manager、裁决 Leader、风险 Agent 和反证 Agent。这个设计终于回答了我在 1.0 中一直没有答好的问题多个 Agent 为什么不是一个 Agent 加几段 Prompt因为这里要刻意制造几种职责隔离调查 Agent 只整理事实、推断和缺失信息不负责判案风险 Agent 与反证 Agent 分别形成独立意见不能互相改写裁决 Agent 必须同时拿到正反两份意见才能提交决定申诉 Agent 只能读取冻结的原案快照和白名单新增证据规则起草 Agent 看不到标记为SCORING的回放集避免针对答案调规则回放指标由后端确定性计算Agent 只能解释不能修改分数最终是否接受候选规则由 Human 决定。多 Agent 的价值不再是“大家在一个群里聊天”而是通过信息边界和权力边界形成可审查的制衡。五、真正让我理解 Agent Infra 的是 WorkOrder 和 Artifact刚接触智能体时我很容易把注意力放在 Prompt 上。但做完这几个版本后我认为 JudgeFlow 里最重要的并不是某一段提示词而是 WorkOrder 和 Artifact。WorkOrder 是后端发出的任务单明确规定谁可以执行当前是哪一步可以读取哪些输入引用必须提交什么类型的产物本次运行的run_id和trace_id是什么。Artifact 则是 Agent 提交的结构化正式产物。它会经过 Schema、身份、任务类型、输入引用、幂等键和内容哈希校验。只有后端验收成功业务状态才会继续推进。所以真实链路不是Agent 说“我完成了” → 系统相信它而是后端创建 WorkOrder → Agent 通过 MCP 领取授权上下文 → Agent 提交结构化 Artifact → 后端校验并持久化 → 后端创建下一张 WorkOrder【配图 06PPT 复用可信裁决机制】使用答辩 PPT 第 4 页「解决方案一职责分离的可信裁决」。它比代码或数据库截图更适合解释 WorkOrder、独立正反意见和后端验收门槛。推荐图注调查不定性、正反意见隔离、后端验收后才允许独立裁决。Matrix 中只传任务 ID、业务 ID、产物引用和简短状态。正式业务事实仍然从 MCP 和后端读取聊天记录不能成为系统真相。这让我意识到Agent Infra 的重点并不是让 Agent “更自由”而是让它在有限权限下仍然可以完成复杂协作并且失败、重试和越权都有明确语义。【配图 07项目前端截图案件详情】截取「案件中心 → 案件详情」中的 Agent 执行流程必须保留调查 Agent、并列的风险/反证 Agent、独立裁决 Agent 以及各自的正式输出。若宽度允许可在右侧同时展开技术证据抽屉。推荐图注风险意见与反证意见来自两张独立任务单裁决结果可以继续追溯到运行和产物证据。六、几个比 Happy Path 更有价值的演示点1. 工具失败不等于没有数据我专门保留了一个固定 TIMEOUT 场景。当调查 Agent 调用转写工具超时时WorkOrder 会进入FAILED案件停在INVESTIGATING也不会生成 EvidenceBundle。页面明确显示TIMEOUT / FAILURE而不是返回一个空列表再让模型误以为“没有发现问题”。这个细节很小却是我认为最接近真实工程的一部分。【配图 08项目前端截图失败语义】在「运行监控」点击“验证 TIMEOUT”后截图保留TIMEOUT / FAILURE、案件仍处于INVESTIGATING以及没有正式 Artifact 的证据。不要只截一条红色提示要让读者看到失败对流程的实际影响。推荐图注工具超时会阻断流程不会被包装成“没有查询到数据”。2. 申诉改判不一定要修改规则申诉改判之后系统会继续做问题归因。如果是POLICY_GAP才进入规则草案和回放如果只是EVIDENCE_GAP流程直接关闭不创建规则草案、回放和审批记录。这条分支避免了一个很常见的错误看到模型判错就默认需要改 Prompt 或改规则。很多问题其实来自证据缺失、工具失败或执行过程而不是规则本身。【配图 09PPT 复用归因与规则演进】使用答辩 PPT 第 6 页「解决方案二先归因、再回放、后审批」。保留EVIDENCE_GAP的停止分支这是本图最重要的信息。推荐图注先判断该不该改再验证改得对不对最后由人决定是否采纳。3. 审批通过不等于生产发布页面上的 Human APPROVE 绑定具体的 proposal 和 replay只记录比赛审批结果。基线规则仍然保持不可变候选版本也不会被偷偷切成生产版本。这既是安全边界也是演示诚实性Demo 做到哪就只声称做到哪。七、从 Java 到 Python真正困难的不是语法作为长期 Java 开发者切到 Python 并没有想象中那么痛苦。Pydantic、SQLAlchemy、Alembic、pytest 这些工具很快就能找到和 Java 生态中相似的心智模型。真正需要适应的是开发重心的变化以前更关注类、接口和服务边界现在要先关注 Agent 的信息边界以前通过调用栈理解系统现在还要把模型调用、工具调用、消息路由和产物验收串成 Trace以前异常通常是显式的现在模型可能用一段看似合理的话掩盖工具失败以前单元测试主要验证代码现在还要验证 Agent 是否越权、是否偷看输入、是否伪造指标以前扩展往往意味着新增抽象现在比赛 Demo 中更重要的能力是拒绝扩展。Java 经验并没有失效。状态机、事务、幂等、不可变对象、Schema 和权限边界反而成了约束 Agent 的基础。只是这些能力不应该再抢走舞台而应该退到 Agent 协作背后成为它可以被信任的原因。八、使用 AI 开发 AI 项目我总结了六条经验1. 先确定一句话再确定架构如果不能用一句话说清评委应该记住什么就先不要画架构图。JudgeFlow 最终想留下的一句话是让有风险的 AI 裁决先经过调查、正反审查、独立裁决和可回放的规则演进。2. 给 AI 的不只是需求还要有“禁止建设清单”只写“要做什么”AI 会自然补齐大量它认为合理的能力。我在 3.0 中明确禁止新增通用平台、额外微服务、RAG、向量库、消息队列、运行时包装器和生产级安全中间层复杂度才真正稳定下来。3. 用演示时长管理范围每增加一个组件都要问它在 6 分钟里会被看到吗它能让核心主张更可信还是只会让我多解释一分钟最终我真的用浏览器按讲解顺序走了一遍计时 399 秒。这个数字比“功能基本完成”更能说明 Demo 是否完成。4. 先跑固定数据再接在线 Agent3.0 先用固定数据和确定性 runner 跑通 Schema、状态机、MCP、回放和页面再接 AgentTeams、Matrix 和在线模型。这样出现问题时才能判断到底是业务内核、工具契约、消息路由还是模型输出出了错。5. 不要只测成功路径除了完整闭环我还保留了工具超时、越权读取、错误 assignee、重复提交、重复审批、非规则归因停止等测试。Agent 系统最危险的往往不是报错而是失败后继续给出一个“像成功一样”的答案。6. AI 可以写方案但人必须守住复杂度预算AI 很擅长把一个方向展开成完整系统也很擅长并行编码和补测试。但删掉什么、哪些能力不值得证明、哪个边界只写在声明里而不做成一套平台仍然需要人做最终判断。九、我现在如何看待这三次重构1.0 并不是废品。它让我确认了确定性执行、人工权力边界和不可变规则版本的重要性。2.0 也不是纯粹的失败。它把 WorkOrder、Artifact、正反隔离、申诉白名单和盲测回放这些关键概念推到了足够具体的位置。只是我付出了 25 张表和大量运行脚本的代价才意识到“严谨”也需要范围。3.0 做的事情其实不是把前两个版本简单删减而是重新排序先证明 Agent 协作价值 → 再定义结构化契约 → 再实现最小确定性内核 → 最后用页面把证据讲清楚最终版本仍然不完美。在线 AgentTeams 链路和最终单页验收是分阶段完成的在线链路已经做过真实动态验证而最终三轮页面验收为了稳定和成本使用的是固定领域 Agent runner没有每次重新调用在线模型。固定回放数据也只能证明当前 Demo 案例不能代表真实生产效果。但我现在更愿意把这些限制明确写出来。因为一个可信的 AI Demo不是看起来什么都能做而是清楚地知道自己证明了什么、没有证明什么。结语如果让我重新参加一次我不会先问“用 Java 还是 Python”“要几个 Agent”“要不要上 RAG”。我会先问三个问题这个任务为什么需要多个角色而不是一个大模型哪些信息和权力必须被隔离协作才有真实价值在 5—8 分钟内我能拿出什么可验证证据第一次参加 AI 比赛我最大的变化不是从 Java 转向 Python而是从“把系统做完整”转向“把要证明的事情做扎实”。对我来说这可能才是学习智能体开发真正的开始。
