# 从 ReAct 到 Agent Team：一个医疗系统研发任务里的信息流与责任边界 — 拆解

**来源：** https://mp.weixin.qq.com/s/JpDAPxDxt8HWdxwuVpOCGg
**作者：** 架构师 / 若飞
**发布时间：** 2026-09-17
**标签：** #主题/AI-Agent #主题/Multi-Agent #主题/Agent协作 #主题/任务一致性 #主题/医疗信息系统 #场景/公众号长文

> 本拆解保留医疗语义、工程边界和外部研究数字的证据限制；外部数字均为原文引用，不视为本地研发承诺。

---

## 核心观点

1. **业务语义先于 Agent 拆分**：先定义事件时间、结果可用时间、空返回和只读边界，再讨论是否并行。
2. **一致性靠外部制品和版本状态**：任务、事实、代码、测试、契约和验收必须可回溯，不能只存在对话上下文。
3. **ReAct 提供反馈，不自动提供正确性**：工具返回和测试断言决定 Agent 能否发现错误。
4. **Agent Team 的价值取决于信息流**：中心化协调与成员直接通信各有代价，任务依赖图比 Agent 数量更重要。
5. **医疗研发必须验证业务含义**：不能以接口成功、单测全绿或“模块完成”替代临床字段和时间语义的集成验收。

---

## 7个分析角度

### 这篇文章主要回答了什么问题
- 在一个只读医疗信息汇总服务中，如何从单 Agent 的 ReAct 循环逐步选择固定工作流、协调者或 Agent Team。

### 为什么这个判断值得关注
- 字段格式都正确时，10:00 才发布的报告仍可能混进 08:00 页面；错误来自业务语义和信息流，而不一定来自代码语法。

### 对个人工作方式的直接启发
- 每次交付都带上输入快照、代码提交、测试报告、假设和未验证项，让别人可以复核而不是只接收结论。

### 对团队协作的启发
- 先建立共享契约和版本状态，再决定哪些适配器能在隔离分支并行；共享制品和契约改动应有明确合并入口。

### 它反对的低效做法是什么
- 反对把空列表当成否定事实、把测试通过当成交付通过、把消息记录当成业务记录，以及在依赖密集任务上盲目增加 Agent。

### 最值得沉淀进知识库的内容
- `commit_sha`、`schema_version`、`fixture_version`、`attempt`、`version`、`result_ref` 等字段构成 Agent 协作的最小可追溯状态。

### 下一步可以怎么继续深入
- 用同一批回放数据比较单 Agent、固定工作流和 Agent Team 的交付时间、返工、缺陷发现和调用成本，再决定是否扩展并行。

---

## 开头钩子

1. 为什么单测全绿，医疗汇总页面仍可能把未来报告显示给早班医生？
2. “最近 24 小时”和“截至 08:00”到底是不是同一个时间条件？
3. 空的过敏接口返回，为什么不能写成“患者无过敏”？
4. 多 Agent 协作最先要拆的是角色，还是责任和契约？
5. 一句“模块已完成”，下游集成真正还缺哪些证据？
6. Agent Team 的收益来自 Agent 数量，还是来自信息流和依赖图？
7. 当工具调用超时，为什么最危险的状态不是失败，而是“状态未知”？

---

## 相关链接

- [[01-ai-agents/架构师-多Agent协作一致性-任务状态与证据]]
- [[01-ai-agents/AI-团队协作-Loop-SDD]]
- [[01-ai-agents/InfoQ-TiDB-薄Agent-Loop厚Control-Plane-Harness]]
- [[02-ai-coding/Loop-Engineering-详解-把反馈循环放进工程现场]]