#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 协作完成”。

项目代码和完整设计文档已经放在 GitHub：RicoPing11/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、Matrix	Manager、Team Leader 和领域 Agent 的组织、路由与按需唤醒
接入与隔离	Higress、Docker	MCP 接入、身份边界和本地可重复运行环境
确定性计算	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：先写演示剧本，再写 Schema

3.0 没有从“还能删掉哪些表”开始，而是从一个更直接的问题开始：

如果只有 5—8 分钟，我要让评委看到哪两个闭环？

答案被固定为：

首次裁决：调查 → 正反独立研判 → 裁决
后续演进：申诉改判 → 归因 → 规则草案 → 回放 → 人工审批

然后我反过来约束实现：任何 Agent、房间、表、MCP 工具、Skill 或服务，如果不能证明主 Demo 没有它就无法完成，就不增加。

3.0 最终收敛为：

项目	最终规模
PostgreSQL 业务表	8 张
MCP 工具	5 个
自研 Skill	4 个
领域 Agent	8 个
协调 Agent	3 个
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

【配图 06｜PPT 复用｜可信裁决机制】

使用答辩 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 或改规则。很多问题其实来自证据缺失、工具失败或执行过程，而不是规则本身。

【配图 09｜PPT 复用｜归因与规则演进】

使用答辩 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. 先跑固定数据，再接在线 Agent

3.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”。

我会先问三个问题：

1. 这个任务为什么需要多个角色，而不是一个大模型？
2. 哪些信息和权力必须被隔离，协作才有真实价值？
3. 在 5—8 分钟内，我能拿出什么可验证证据？

第一次参加 AI 比赛，我最大的变化不是从 Java 转向 Python，而是从“把系统做完整”，转向“把要证明的事情做扎实”。

对我来说，这可能才是学习智能体开发真正的开始。

---