教育不是把水桶装满，而是点燃一团火。
—— 通常归于 W.B. Yeats，转述自 Plutarch
教学很难。在许多方面，它比下棋或折叠蛋白质更难。那些问题有清晰的目标函数，而教育没有。要教得好，你需要读懂一个你无法直接观察的大脑，校准一个会随着每次互动而变化的挑战水平，并且还要让整个体验不像障碍赛，而更像一场对话。一个能够做到这一点的智能体，如果能个性化课程、跨几十项能力追踪进展，并实时提供反馈，就可以以任何人类机构都无法匹配的规模，民主化专家级教学。
然而，挑战并不止于个体学习者。知识工作中一些最重要的问题，需要的不是单个聪明智能体，而是一个能够协作、辩论并综合不同视角的协调集合，从而得到任何单个个体都无法独立产生的解决方案。集体智能领域研究的是：一组智能体，每个都拥有部分知识和有限推理能力，如何产生超越个体贡献总和的涌现行为。
本章将覆盖以下主题：
- 教育智能体
- 集体智能体
技术要求
要运行本章中的示例，你需要准备以下内容：
- Python 3.10 或更高版本
- 以下 Python 包：
openai==1.40.0、numpy==1.26.4、networkx==3.3和python-dotenv==1.0.1 - 一个 OpenAI API key，并具备访问
gpt-4o模型的权限
本章所有代码示例可在本书 GitHub 仓库中找到：
https://github.com/PacktPublishing/30-Agents-Every-AI-Engineer-Must-Build/chapter15.
教育智能体
教学在本质上是一项诊断性和适应性工作。一个有效教师会持续评估学生知道什么，识别缺口和误解，选择最合适的下一项活动，并以正确难度交付它，然后根据学生回应调整路径。这种感知、推理和行动循环，自然映射到第 1 章中的认知循环，只是在教育语境中会带有反映教学独特需求的领域特定变化。
教育智能体以计算方式复制这一循环。它维护每个学生知识状态的丰富、持续演化模型，规划个性化学习路径，通过多种模态交付教学，并基于观察到的表现优化自身理解。该智能体并不旨在替代人类教师。它通过处理个性化教学中计算密集的一侧来增强教师：跨几十名学生追踪数百项细粒度能力，发现表现数据中预示新兴困难的模式，并生成即时、具体的反馈，而这是任何单个教师都难以在三十人课堂中持续做到的。
感知模块处理多样化学习信号：测验回答、代码提交、任务耗时数据、求助行为和自然语言问题。推理模块应用教学逻辑，尊重知识领域中层级化、依赖先修条件的结构。行动模块生成适合教育工作流的输出，从选择下一道练习，到撰写针对具体误解的反馈。
一个关键设计原则，是我们称为 pedagogical alignment，也就是教学对齐。智能体作出的每个决策，都必须扎根于既有学习科学。这不是哲学问题，而是工程要求。一个只优化任务完成率，却不考虑认知负荷、间隔重复或最近发展区的智能体，会产生短期看似高效，但无法实现持久知识获得的学习体验。教学对齐通过规划模块中的约束层执行：该层会在执行前，根据一套教学设计原则库评估候选行动。
教育智能体运行在较高形式复杂度上，因此需要严谨数学基础。从形式上看，该智能体被建模为一个 Partially Observable Markov Decision Process（POMDP，部分可观测马尔可夫决策过程），将第 13 章建立的随机决策框架扩展到教学领域。
在这个语境中需要 POMDP，是因为最关键变量——学生真实掌握程度——是系统无法直接访问的隐藏状态。智能体只能依赖有噪声的感知代理，包括：
- 测验和评估回答
- 详细代码提交模式
- 任务耗时和求助行为等遥测数据
该模型的核心是 belief state，即 b(s)，它表示学习者可能知识状态上的概率分布。这个状态相当于人类教师关于学生理解程度直觉的计算版本。智能体的目标，是选择教学行动，例如呈现内容、安排复习或提供提示，使这个隐藏状态朝掌握阈值移动，即使该状态本质上仍然不确定。对大型知识图谱精确求解完整 POMDP 通常计算上不可行。接下来的小节会将问题拆解为可处理组件：Bayesian Knowledge Tracing 维护学生掌握程度的 belief state，课程规划器使用最近发展区启发式选择教学行动，间隔重复调度器优化复习时机。三者共同近似 POMDP 的 observe–plan–act 循环，而无需显式值迭代求解器。
用可处理组件近似 POMDP
该架构将完整 POMDP 拆解为三个可处理组件，每个组件负责 observe–plan–act 循环中的一个元素。第一，Bayesian Knowledge Tracing 充当 belief-state 估计器：它维护学生对每项技能掌握程度的概率分布 b(s)，并在每次观察到回答后，使用 slip 和 guess 参数作为观察模型更新该分布。第二，Curriculum Planner 负责行动选择：给定当前 belief state，它识别预期学习收益最高的技能，并选择下一项教学目标，用最近发展区启发式替代计算昂贵的值迭代。第三，Spaced Repetition Scheduler 捕捉 POMDP 中时间折扣维度：它决定何时复习先前已掌握技能，优化强化时机，以最大化长期保持。三者共同覆盖 POMDP 的状态估计、行动选择和时间规划阶段，同时保持每个模块可独立测试且计算高效。
个性化课程规划
教育智能体的基础是课程规划引擎。传统课程遵循线性序列：所有学生按照相同顺序、相同节奏遇到相同主题。这忽略了一个已被充分证实的事实：学习者带着不同先验知识而来，以不同速度学习，并且需要不同练习量。智能体的课程规划器通过构建个性化学习路径来处理这些限制，并基于学生展示出的能力实时适应。
课程在内部表示为一个知识图谱：一个有向无环图，其中节点表示学习目标，边表示先修关系。每个目标都关联教学活动，例如阅读、视频、练习、项目，以及评估项，例如测验、编程挑战和开放式问题。这种图结构表示让智能体能够围绕依赖关系推理，识别多个穿越材料的有效路径，并选择最匹配每个学生当前状态的路径。
规划问题可以建模为知识图谱 G = (V, E) 上的约束优化。对于拥有当前掌握状态 M 的学生，规划器要寻找一个目标序列 S = (v_1, v_2, …, v_k)，该序列满足先修约束，同时最大化单位教学时间的预期学习收益。这是 DAG 上约束最短路径问题的一个变体，可以使用拓扑排序和动态规划高效求解。
每个候选目标的预期学习收益，借鉴 Vygotsky 的 zone of proximal development（ZPD，最近发展区）。对于在目标 j 上掌握水平为 m 的学生，以及难度为 d 的活动，其预期收益为：
G(m, d) = α · exp( −(d − m − δ)² / (2σ²) )
其中，δ 表示当前掌握程度与任务难度之间的最佳偏移，通常比当前掌握水平高 0.1 到 0.3；σ 控制有效学习区间宽度；α 是缩放常数。这个高斯模型捕捉了一个经验现实：太容易的任务产生极少学习，太难的任务导致挫败和 disengagement，而落在最近发展区甜蜜点上的任务产生最大收益。
图 15.1 展示这些组件如何组合在一起。该架构将第 1 章的通用认知循环适配到教育领域，每个模块对应教学循环中的一个不同阶段。
图 15.1——教育智能体架构
图 15.1 展示了认知循环如何适配教育语境。感知模块摄取学生交互数据，学生模型维护跨知识图谱的概率能力估计，而课程规划器、内容交付引擎和反馈生成器通过将这些估计转化为个性化教学来闭合循环。
知识图谱粒度极其重要。定义过宽的目标，例如“理解面向对象编程”，会阻碍细粒度决策。定义过窄的目标，例如“知道 Python 用缩进表示代码块”，会让图变得难以管理。实践中，单一概念或技能级别的目标最平衡，每个目标大约需要 15 到 45 分钟教学时间。在生产中，图会在启动时从 Neo4j 数据库加载，并预计算拓扑排序，将先修检查从 O(|V| × |E|) 降低到 O(|V|)。
规划器的任务，是回答一个简单的操作问题：基于我们当前对学生掌握程度的判断，他们下一步应该做什么，既可行又最有成效？下面的实现会过滤先修条件已满足的目标，然后使用与最近发展区对齐的预期学习收益启发式，对剩余候选目标排序。这段代码实现了教育智能体课程规划器中的核心目标选择步骤。给定一个学生 ID，它会使用智能体当前掌握估计，以及知识图谱中编码的先修结构，选择接下来几个学生既准备好了、又最可能从中受益的学习目标。
具体来说，规划器做两件事：首先过滤掉任何先修条件尚未掌握的目标，这样导师不会跳过基础概念；随后使用预期收益启发式，对剩余候选排序，该启发式偏好处于学生最近发展区内的目标，并优先考虑能解锁许多下游主题的高杠杆概念。在查看规划器实现之前，我们需要它依赖的数据结构。教育智能体中的每个组件，包括课程规划器、间隔重复调度器和反馈生成器，都会查询一个共享的 StudentModel 类，该类维护学习者当前掌握状态。下面的类定义了下游组件消费的最小 API 表面：
class StudentModel:
"""Maintains per-student mastery state across all
learning objectives. Updated after every interaction."""
def __init__(self, student_id: str,
knowledge_graph):
self.student_id = student_id
self.knowledge_graph = knowledge_graph
self.mastery = {
obj.id: {
"p_mastery": 0.1,
"attempts": 0,
"last_seen": None,
"recent_errors": [],
}
for obj in knowledge_graph.objectives
}
def get_mastery_state(self) -> dict:
"""Return current mastery probabilities."""
return {
oid: state["p_mastery"]
for oid, state in self.mastery.items()
}
def get_recent_errors(self, objective_id: str):
return self.mastery[objective_id]
.get("recent_errors", [])
def get_mastered_objectives(self,
threshold=0.85):
return [
oid for oid, state
in self.mastery.items()
if state["p_mastery"] >= threshold
]
def update_mastery(self, objective_id: str,
new_p: float, error=None):
state = self.mastery[objective_id]
state["p_mastery"] = new_p
state["attempts"] += 1
if error is not None:
state["recent_errors"].append(error)
state["recent_errors"] = (
state["recent_errors"][-5:])
mastery 字典存储每个目标的概率估计、尝试次数和最近错误滚动窗口。get_mastery_state() 方法返回课程规划器消费的快照，而 update_mastery() 会在每次学生交互后由 Bayesian Knowledge Tracing（BKT）更新逻辑调用。有了这个类之后，CurriculumPlanner 可以直接查询学生模型：
class CurriculumPlanner:
def __init__(self, knowledge_graph, student_model,
content_library):
self.graph = knowledge_graph
self.model = student_model
self.content = content_library
self.mastery_threshold = 0.8
def get_next_objectives(self, student_id: str,
n: int = 3) -> list[LearningObjective]:
"""Select the next learning objectives based on
student mastery state and prerequisite constraints."""
mastery = self.model.get_mastery_state(student_id)
eligible = []
for objective in self.graph.get_all_objectives():
prereqs = self.graph.get_prerequisites(objective.id)
prereqs_met = all(
mastery.get(p.id, 0.0) >= self.mastery_threshold
for p in prereqs
)
not_mastered = (
mastery.get(objective.id, 0.0)
< self.mastery_threshold
)
if prereqs_met and not_mastered:
eligible.append(objective)
ranked = sorted(
eligible,
key=lambda obj: self._expected_gain(
obj, mastery, student_id
),
reverse=True
)
return ranked[:n]
def _expected_gain(self, objective, mastery,
student_id) -> float:
"""Estimate learning gain using ZPD-aligned
Gaussian model with downstream impact."""
current = mastery.get(objective.id, 0.0)
difficulty = objective.estimated_difficulty
delta = 0.2
sigma = 0.25
zpd_score = math.exp(
-((difficulty - current - delta) ** 2)
/ (2 * sigma ** 2)
)
downstream = len(
self.graph.get_dependents(objective.id)
)
return zpd_score * (1 + 0.1 * downstream)
关于 ZPD 常数的说明：
delta = 0.2 将当前掌握程度和任务难度之间的最佳差距设为高于学习者水平 20%，使目标正好落在 Vygotsky 所描述的最近发展区内。
sigma = 0.25 控制有效学习区间的宽度，决定当任务过易或过难时，收益函数下降得有多快。
这些默认值来自入门编程课程历史 cohort 数据校准，应被视为可调超参数：面向更低龄学习者或陌生领域的部署，可能需要更窄的 sigma，也就是更紧密的脚手架；高级学习者往往受益于更大的 sigma，也就是更大的挑战跨度。
上面的代码作出了两个架构承诺，如果只把它当成“选择逻辑”看，很容易错过。第一，它分离了资格判断和排序。资格由知识图谱执行：prereqs_met 确保智能体永远不会分配先修链尚未准备好的目标，这是在真实部署中防止课程漂移和缺口复合的具体机制。排序则编码教学法：mastery_threshold 是系统对“准备好了”的定义，而 _expected_gain() 使用 ZPD 形状的分数，偏好略高于学生当前掌握程度的任务（delta），并惩罚过易或过难任务（sigma）。最后的 downstream 乘数是一种务实调度偏置：能解锁许多依赖目标的学习目标被视为更高杠杆，因此系统倾向于较早清除瓶颈，例如在尝试嵌套迭代模式之前先掌握循环不变量。实际使用中，这意味着导师能够表现得像一位优秀教师：它不是简单选择下一节未读课程，而是基于学生模型当前 belief state 作为输入信号，选择一个学生确实准备好学习的下一个高收益目标。
一个经常让教育智能体团队意外的问题是 cold-start，即冷启动。当学生首次进入系统时，智能体没有交互历史，没有可靠的掌握程度估计，也没有关于常见误解的证据。如果智能体错误猜测起点，它会以两种可预测方式失败。它可能高估学习者，从一开始就给出晦涩材料，导致快速脱离。也可能低估学习者，交付过于简单的内容，同样会破坏体验，因为这传递出系统没有认真关注他们的信号。
一个实用解决方案是将 onboarding 视为显式诊断协议，而不是一句非正式的“告诉我你知道什么”。一种有效方法是使用基于 Item Response Theory（IRT，项目反应理论）的短自适应分班测试。该测试不是为了给学生打分，而是为了给智能体的学生模型生成一个初始 belief state：在每个先修领域上的起始能力估计，以及不确定性。在生产中，这个初始估计会成为课程规划、提示策略、节奏，以及何时测试与何时解释的种子。
IRT 在这里有价值，因为它将朴素诊断中常常混在一起的三个因素分离开来：学生能力、题目难度和题目信息量。在 two-parameter logistic（2PL）模型中，正确回答概率为：
P(correct | θ, a, b) = 1 / (1 + exp(−a(θ − b)))
其中，θ 是学习者在被评估技能上的潜在能力，b 是题目难度，a 是 discrimination，也就是区分度，表示该题在难度阈值附近区分稍低于与稍高于该阈值学生的能力有多强。高 a 题目能提供更多关于学生是否真正理解概念的信息，而低 a 题目往往表现得像“有噪声”的指标，常常因为可以通过模式匹配或应试策略答对。
考虑一个具体 onboarding 用例：一个编程导师需要将学生放入入门 Python 的合适轨道。系统关注 variables、conditionals、loops 和 basic list manipulation 等先修项。第一次交互时，智能体无法从一次对话中可靠推断这些内容，因为学生可以用并不预测表现的方式描述自己的背景。因此，智能体会运行一个短自适应诊断，包含一些微题目，例如追踪循环输出，预测布尔表达式结果，修复列表索引 bug，或解释简单函数。每道题都有来自过往 cohort 校准的 (a, b) 值。
自适应算法从中等难度题目开始，然后根据回答更新当前能力估计。如果学生答对，系统提高 θ 并选择接近新估计的更难题目。如果学生答错，系统降低 θ 并选择更容易的题目。目标不是覆盖完整教学大纲，而是快速将问题集中到学生从“很可能答对”过渡到“很可能答错”的边界。这个边界正是题目对分班最有信息量的地方。实践中，这种方法用远少于固定测试的题目数量就能得到稳定估计，通常在 10–15 题范围内，因为每道题都是基于当前不确定性最大化信息量选择的。
诊断完成后，智能体可以做到“纯聊天”导师经常难以做到的事：解释并操作化分班决策。例如，学生可能在 variables 和 conditionals 上得分高，但 loops 上不确定。课程规划器随后可以把他们路由到一个对 loops 提供更多脚手架的轨道，同时加速通过前面单元。提示策略也可以相应设定：当学生遇到 loop 相关练习时，智能体优先采用引导式追踪、更小子问题和频繁理解检查，而不是直接给出完整答案。诊断结果也成为教学审计轨迹的一部分：系统可以解释为什么选择某个起点，教师也可以在需要时覆盖分班。
下面的清单使用 2PL IRT 模型实现一个自适应分班测试。它选择在当前能力估计下最大化信息量的题目，在每次回答后更新估计，并在标准误差低于可配置阈值时终止：
class AdaptivePlacementTest:
def __init__(self, item_bank, se_threshold=0.3):
"""item_bank: list of dicts with keys
'skill', 'a' (discrimination), 'b' (difficulty),
'text', 'answer'."""
self.items = item_bank
self.se_threshold = se_threshold
self.theta = 0.0 # initial ability estimate
self.responses: list[tuple] = []
# ---- 2PL probability ----
@staticmethod
def p_correct(theta, a, b):
import math
return 1.0 / (1.0 + math.exp(-a * (theta - b)))
# ---- Fisher information at current theta ----
def _information(self, item):
p = self.p_correct(self.theta, item['a'], item['b'])
return (item['a'] ** 2) * p * (1 - p)
def select_next_item(self, used_ids):
"""Pick the unused item with maximum information."""
remaining = [i for i in self.items
if id(i) not in used_ids]
if not remaining:
return None
return max(remaining, key=self._information)
def update_theta(self):
"""Newton-Raphson MLE update over all responses."""
import math
theta = self.theta
for _ in range(25): # max iterations
num = den = 0.0
for item, correct in self.responses:
p = self.p_correct(theta, item['a'],
item['b'])
num += item['a'] * (correct - p)
den += (item['a'] ** 2) * p * (1 - p)
if abs(den) < 1e-10:
break
theta += num / den
self.theta = theta
def standard_error(self):
import math
info = sum((it['a']**2)
* self.p_correct(self.theta, it['a'], it['b'])
* (1 - self.p_correct(self.theta, it['a'],
it['b']))
for it, _ in self.responses)
return 1.0 / math.sqrt(info) if info > 0 else float('inf')
def run(self, get_response_fn):
"""Execute adaptive test. get_response_fn(item)->bool"""
used = set()
while True:
item = self.select_next_item(used)
if item is None:
break
correct = get_response_fn(item)
self.responses.append((item, int(correct)))
used.add(id(item))
self.update_theta()
if (len(self.responses) >= 5 and
self.standard_error() < self.se_threshold):
break
return {'theta': self.theta,
'se': self.standard_error(),
'items_used': len(self.responses)}
学生进度追踪：贝叶斯更新循环
有效个性化不只是记录学生遇到了哪些主题。它需要一个工作模型，表示学生知道什么、他们能多可靠地应用它，以及这些知识如何随着练习变化。教育智能体使用 BKT 来维护这一模型。BKT 将每个学习目标视为智能体无法直接观察到的隐藏掌握状态。相反，它从提交、测试结果、提示使用情况和特征性错误模式等可观察证据推断掌握程度。
要理解智能体如何“读取”学生理解，最好将 BKT 参数锚定到一个具体教学工作流。考虑一个 Python 编程导师追踪 “Loop termination and iteration control” 这一目标。该模型使用四个参数，它们与工程和教学清晰对应：
Initial mastery（P(L₀)） ：在第一次相关练习前，智能体对学生已经知道该概念的起始信念。被放入中级轨道的学生，会比新手学习者有更高先验。
Transition probability（P(T)） ：一次学习机会导致真实学习发生的概率。学习机会可以是带反馈的练习尝试、worked example，或目标提示序列。在实践中，P(T) 捕捉该目标上交互设计的有效性。
Slip rate（P(S)） ：即使学生已经掌握概念，仍然答错的概率。在编程导师中，slip 很常见：缺少冒号、缩进错误，或轻微 off-by-one bug，都可能造成失败，尽管概念理解是存在的。
Guess rate（P(G)） ：即使没有掌握，仍然答对的概率。在代码挑战中，guess 可能通过不断试错直到测试通过、复制模式，或偶然碰到正确条件发生。
这四个项解释了为什么智能体不能将“正确”简单等同于“已掌握”，也不能将“错误”等同于“未掌握”。相反，它在每次交互后更新自身 belief state。
更新本身是两步贝叶斯计算。第一，智能体根据观察结果（正确或错误）计算学生已掌握目标的后验概率。第二，它应用学习转移，考虑学生可能从这次交互本身学到了东西。下面的实现封装了这一逻辑。
def bkt_update(p_mastery: float, correct: bool,
p_transit: float = 0.1,
p_slip: float = 0.05,
p_guess: float = 0.2) -> float:
"""Compute updated mastery probability after one
observation using standard BKT.
Args:
p_mastery: prior P(L_n), current mastery belief
correct: whether the student response was correct
p_transit: P(T), probability of learning per opportunity
p_slip: P(S), probability of slip given mastery
p_guess: P(G), probability of guess given no mastery
Returns:
Updated P(L_{n+1}) after incorporating evidence."""
# Step 1: posterior P(L_n | observation)
if correct:
p_correct_given_L = 1.0 - p_slip
p_correct_given_not_L = p_guess
else:
p_correct_given_L = p_slip
p_correct_given_not_L = 1.0 - p_guess
p_obs = (p_correct_given_L * p_mastery
+ p_correct_given_not_L * (1 - p_mastery))
p_posterior = (p_correct_given_L * p_mastery) / p_obs
# Step 2: learning transition
p_updated = (p_posterior
+ (1 - p_posterior) * p_transit)
return p_updated
把它放到上面定义的 loop-iteration 场景中看，假设学生从 P(L₀)=0.1 开始，也就是低先验，导师使用 P(T)=0.1、P(S)=0.05、P(G)=0.2。第一次正确提交后，bkt_update(0.1, True) 返回约 0.34：智能体对掌握的信念大约增加到三倍，但仍低于 0.85 阈值，因为一次成功可能是猜对。第二道练习产生错误后，bkt_update(0.34, False) 会将估计降回约 0.28，反映在这个掌握水平上，错误更可能意味着真实缺口，而不是 slip。智能体此时会选择诊断动作，而不是推进课程。
上面的独立函数一步步说明了 BKT 算法。对于生产集成，相同逻辑应封装在一个类中，使 StudentModel 可以将其作为属性持有。下面的 BKTTracker 类将两步更新包装成一个可复用组件，并支持可配置参数。
class BKTTracker:
"""Encapsulates Bayesian Knowledge Tracing for
integration with StudentModel."""
def __init__(self, p_transit=0.1,
p_slip=0.05, p_guess=0.2):
self.p_transit = p_transit
self.p_slip = p_slip
self.p_guess = p_guess
def update(self, p_mastery: float,
correct: bool) -> float:
"""Return updated P(L) after one observation."""
if correct:
p_correct_L = 1.0 - self.p_slip
p_correct_not_L = self.p_guess
else:
p_correct_L = self.p_slip
p_correct_not_L = 1.0 - self.p_guess
p_obs = (p_correct_L * p_mastery
+ p_correct_not_L * (1 - p_mastery))
posterior = (p_correct_L * p_mastery) / p_obs
return (posterior
+ (1 - posterior) * self.p_transit)
当 StudentModel 收到观察结果时，其 update_mastery() 方法会调用 tracker.update() 计算新后验，并存储结果。该设计使 BKT 参数可以按课程配置，同时保持下游组件依赖的简单 API。
假设给学生布置这个任务：
Write a for loop that sums all even numbers in a list.
学生提交如下代码：
total = 0
for x in nums:
if x % 2 == 0:
total += x
print(total)
测试通过。智能体现在需要更新对 “Loop iteration with conditional filtering” 的掌握估计。一次正确提交会提高掌握概率，但该更新会被猜测可能性调低。如果学生请求了多个提示，或者系统观察到多次快速编辑并反复运行测试，智能体可能将该证据视为较弱。在 BKT 术语中，更高的 P(G) 会使模型更谨慎，不会过度奖励一次成功。
现在考虑下一道练习，它故意相似，但改变了失败模式：
Sum even numbers, but stop early if you encounter a negative value.
学生写下：
total = 0
for x in nums:
if x < 0:
break
if x % 2 == 0:
total += x
这次测试失败，因为 break 条件在该任务变体中位置不对，或者学生误解了循环什么时候终止。错误回应会降低掌握估计，但智能体仍然必须解释该错误。如果失败是缩进或简单语法错误导致，slip 更可能是解释。如果失败反映对控制流的结构性误解，更新就应该体现真实缺口。
更新后的后验概率正是 BKT 在行动选择上有用的原因。智能体下一步行动不是任意的，而是基于更新后的 belief：
- 如果掌握程度仍高，且错误看起来像 slip，例如缩进或缺少冒号，智能体应该提供最小修正，并让学生保持原路径。系统避免过度补救。
- 如果掌握程度明显下降，智能体应切换到诊断动作：一个简短追踪问题，例如 “What is the value of total after the third iteration?”，或一个聚焦
break语义的微练习。这可以快速降低不确定性。 - 如果学生连续答对，但模型仍估计掌握度较低，智能体可以推断正确信号很可能由猜测行为驱动。此时，它会安排一个更具区分度的评估：一个不能通过复制上一题模式解决的问题，例如要求学生预测带嵌套条件的循环行为，或调试一个失败实现。
通过维护一个运行中的概率，而不是二元标签，智能体可以解释为什么作出这些选择。它可以告诉教师：“学生近期正确率与其提示模式和响应时间不一致，因此我们正在用迁移任务确认掌握程度”，或者“这看起来是在持续成功后的 slip，因此我们不会让学生回退”。
自适应学习技术
有了稳健学生模型和课程规划器后，智能体就可以部署传统课堂中很难实现的自适应技术。这些技术运行在多个时间尺度上。
在微观层面，智能体实现 adaptive scaffolding，即根据观察到的表现动态调整支持。当学生在编程练习中遇到困难时，智能体不会直接给出答案。相反，它会走过四个逐级增强的层级。第一层是概念性轻推：一个问题，将注意力引导到正确概念上，但不指向具体错误。第二层是定位：“问题在你的循环体中某处”。第三层是结构性提示，可能是伪代码或部分模板。第四层，也是只有当学生仍然卡住时，才给出一个类似问题的 worked example，然后提示学生应用相同模式。智能体只有在再次错误提交后，才会上升一个层级。层级之间的等待时间会根据每个学生历史响应模式校准，整个序列被实现为 LangGraph 工作流中的状态机。
在中观层面，mastery-based progression 只在学生展示出足够先修理解后推进学生。不同于基于时间的进度推进，它防止基础缺口复合。掌握阈值也不是固定常数：被许多下游目标高度依赖的先修项，需要更高阈值。
在宏观层面，learning path diversification 承认掌握画像相似的学生，可能受益于不同教学方法。有些人适合先具体例子后抽象原则，也就是归纳式；有些人偏好先理论再应用，也就是演绎式。智能体维护一个偏好模型，并基于跨模态 engagement 和 outcomes 更新该模型。
自适应引擎还实现 long-term retention 的 spaced repetition，即间隔重复。为了操作化这一教学原则，智能体使用修改版 SM-2（SuperMemo-2）算法，为每个已掌握目标维护具体复习计划。该算法是一种计算方法，会根据学习者先前表现决定复习某项信息的最佳时机。其核心逻辑如下：
递增间隔：将信息从短期记忆迁移到长期记忆的最高效方式，是以递增间隔复习；每次成功回忆都会将下一次计划复习推到更远未来。
回忆质量：该算法使用质量分数，通常从 0 到 5，来调整某个概念的 ease factor。
自适应强化：如果学生成功回忆概念，间隔会增长；如果失败，该概念会被重置为每日复习，直到重新建立掌握。
当计划显示某个概念有被遗忘风险时，智能体会将复习活动穿插到当前会话中。下面的清单展示这一间隔重复调度器：
class SpacedRepetitionScheduler:
def __init__(self, student_model):
self.model = student_model
def get_due_reviews(self, student_id: str,
max_reviews: int = 5) -> list[Review]:
"""Identify objectives due for review based on
spaced repetition schedule."""
mastered = self.model.get_mastered_objectives(
student_id
)
due = []
now = datetime.utcnow()
for objective_id, metadata in mastered.items():
next_review = metadata.get("next_review")
if next_review and next_review <= now:
days_overdue = (now - next_review).days
priority = min(days_overdue / 7.0, 1.0)
due.append(Review(
objective_id=objective_id,
priority=priority,
interval=metadata.get("interval", 1),
repetitions=metadata.get("reps", 0)
))
due.sort(key=lambda r: r.priority, reverse=True)
return due[:max_reviews]
def update_schedule(self, student_id: str,
objective_id: str,
quality: int) -> None:
"""Update review schedule using SM-2 algorithm.
Quality: 0 (complete failure) to 5 (perfect)."""
meta = self.model.get_objective_metadata(
student_id, objective_id
)
reps = meta.get("reps", 0)
interval = meta.get("interval", 1)
ease = meta.get("ease_factor", 2.5)
if quality >= 3:
if reps == 0:
interval = 1
elif reps == 1:
interval = 6
else:
interval = int(interval * ease)
reps += 1
else:
reps = 0
interval = 1
ease = max(1.3, ease + 0.1 - (5 - quality)
* (0.08 + (5 - quality) * 0.02))
next_review = datetime.utcnow() + timedelta(
days=interval
)
self.model.update_objective_metadata(
student_id, objective_id,
reps=reps, interval=interval,
ease_factor=ease, next_review=next_review
)
这个调度器做的不只是创建日历提醒。它提供了与学生模型掌握估计和课程规划器前瞻选择互补的保持层。get_due_reviews() 方法扫描已掌握目标，并基于某个目标逾期多久计算优先级分数，确保会话把时间分配给真正有衰退风险的概念，而不是均匀复习所有内容。
update_schedule() 方法则操作化了一个核心教学洞察：重要的不是花费时间，而是成功提取。一个学生如果能干净地回忆某个概念（高质量），就获得更长间隔和更高 ease factor，将下一次复习推远；如果回忆失败，重复次数重置，间隔收缩，触发近期强化。
一个具体用例是：Python 学习者最近“掌握”了 list slicing，但两周后开始出现边界错误。调度器不会等到错误再次出现在评分作业中才行动，而是在 next_review 到期时立刻浮现 slicing 进行复习。学生在这次简短提取活动中的表现，会直接更新未来计划。如果学生回答正确但犹豫并需要提示，可以将其编码为中等质量分数，让间隔增长，但保持保守。如果他们完全无法重构该概念，算法会重置间隔，并强制快速再次遇到该概念，防止掌握逐渐漂移为脆弱、易错知识。从架构角度看，这就是智能体让“持久性”变得可行动的方式：它将前文“学生进度追踪：贝叶斯更新循环”中 BKT 追踪的保持—衰退动态，转化为一个具体运行时策略，决定何时中断新内容，以保护长期保持。
上面描述的组件，包括课程规划器、BKT tracker、间隔重复调度器和自适应脚手架，构成了一个完整但抽象的架构。下面的案例研究会把它们落到具体部署中：一个教授入门 Python 并提供定制反馈的编程导师，展示每个组件如何参与真实教学工作流。
案例研究：带定制反馈的编程导师
为了看到这些组件如何协同工作，我们考察一个教育智能体的完整部署：一个 Python 编程导师，支持学习者从第一行代码一路进入中级挑战。
该导师运行在一个包含 247 个学习目标的知识图谱上，这些目标分布在 12 个主题 cluster 中：数据类型、控制流、函数、数据结构、文件 I/O、错误处理、面向对象编程、模块与包、测试、算法、调试和软件设计模式。
在生产中，该导师被拆分为五个可在 Kubernetes 上独立扩展的微服务：
- Student Model Service：维护掌握估计，使用 PostgreSQL 持久化，并用 Redis 缓存。
- Curriculum Planner Service：从 Neo4j 加载知识图谱。
- Content Delivery Service：从 CDN 支撑的对象存储提供材料。
- Assessment Engine：在带 10 秒执行超时的沙盒 Docker 容器中运行学生代码自动测试。
- Feedback Generator Service：调用 LLM API 并传入学生上下文，使用 prompt caching，并在高延迟情境下使用基于模板的 fallback。
自适应循环由 LangGraph 编排，定义节点用于 readiness assessment、content delivery、response collection、submission evaluation、feedback generation，以及 human checkpoint。当出现需要标记的情况，例如反复失败、痛苦信号或疑似不诚实时，human checkpoint 会通过 Slack 通知教师。LangGraph 使用 Postgres 支撑的持久化，确保服务重启后会话状态仍能保留。
新学生会接受一个 15 题自适应分班测试，该测试使用来自 12,000 名历史学生的 IRT 参数校准。一个有其他语言经验的学生，可能展示出一般编程概念掌握，但在 Python 特定语法上估计较低。
当学生提交代码时，评估管线执行多层分析。自动测试验证正确性。静态分析（Ruff、pylint）检查风格和反模式。然后，misconception detection 模块开始运行。
误解检测器使用两阶段管线。第一阶段是快速规则分类器，将代码与大约 180 个已知 Python 误解模式匹配，这些模式被定义为 AST 节点模式和输出签名的组合。该阶段在 50 ms 内运行，并捕获约 70% 常见误解。当规则阶段没有匹配或置信度低时，第二阶段会用代码、错误输出和近期错误历史调用 LLM。这种混合方法将平均反馈延迟从 8 秒（纯 LLM）降至 2.5 秒，同时保持诊断准确率超过 85%。
下面的代码实现了 FeedbackGenerator 类。该组件代表教育认知循环中关键的 “Action” 阶段，在这里系统内部推理最终表现为面向学习者的教学干预。该实现目标是合成一条个性化、上下文感知的反馈消息，而不只是简单正确/错误信号。通过整合学生当前掌握水平、近期错误模式和检测到的具体误解，生成器使用 LLM 驱动的提示来产出一种“概念性轻推”。这种方法确保学生被引导去独立发现解决方案，而不是直接看到最终答案。有了课程规划和学生知识追踪后，智能体必须通过交付教学闭合循环。下面的反馈引擎实现展示了如何将原始诊断数据转化为支持性对话，确保每次回应都与学生具体学习路径对齐。
class FeedbackGenerator:
def __init__(self, llm_client, student_model,
misconception_library):
self.llm = llm_client
self.model = student_model
self.misconceptions = misconception_library
def generate_feedback(self, student_id: str,
exercise: Exercise,
submission: str,
test_results: TestResults
) -> Feedback:
"""Generate personalized feedback that addresses
the student's specific learning needs."""
mastery = self.model.get_mastery_state(student_id)
history = self.model.get_recent_errors(
student_id, n=10
)
detected = self.misconceptions.detect_rule_based(
submission, exercise.objective_ids
)
if not detected or detected.confidence < 0.7:
detected = self.misconceptions.detect_llm(
submission, exercise, history
)
prompt = f"""You are an expert Python tutor.
The student is working on: {exercise.description}
Their solution:
```python
{submission}
```
Test results: {test_results.summary}
Student context:
- Current mastery of {exercise.topic}: \
{mastery.get(exercise.primary_objective, 0.0):.0%}
- Recent error patterns: {history}
- Detected misconceptions: {detected}
Generate feedback that:
1. Acknowledges what the student did correctly
2. Identifies the specific error without revealing
the complete solution
3. Asks a guiding question that leads toward
discovering the fix independently
4. If a misconception is detected, address the
underlying conceptual confusion"""
response = self.llm.generate(prompt)
return Feedback(
content=response,
misconceptions_addressed=detected,
mastery_updates=self._compute_updates(
student_id, exercise, test_results
)
)
上面的代码操作化了一个容易说、很难做的原则：反馈应该诊断学生为什么失败，而不仅仅报告他们失败了。该方法首先组装学生当前掌握估计和一小段近期错误窗口，因为同一个错误提交在不同上下文下意味着不同事情。
随后它执行两阶段误解检测：快速规则分类器会将提交与已知模式库匹配，而当第一阶段不确定时，才调用第二阶段 LLM 诊断。这种混合设计不是装饰。它是一种延迟和可靠性策略：规则阶段可以低成本、一致地捕捉常见误解；LLM 阶段则覆盖新颖或组合型错误，而无需让每次交互都承担 LLM 调用成本。提示本身被结构化为教学契约。它强制模型承认正确部分、定位错误但不泄露完整解，并提出引导问题，保持学生主体性。
实践中，这就是智能体防止两类教学系统常见失败的方式：“盖章式表扬加正确答案”和“泛泛建议，无法连接学生真实误解”。通过同时返回反馈内容和计算出的掌握更新，组件也会将循环闭合回学生模型，确保反馈不是一条孤立消息，而是在更大教学架构中会改变状态的行动。
为了看到这些组件如何作为统一系统工作，考虑一名学生穿越教育智能体的路径。新学习者 Alex 进入 Python 编程导师，没有任何过往交互历史。
阶段 1——分班：基于 IRT 的诊断呈现 12 个自适应微题目。Alex 正确回答 variables 和 conditionals，但在 loop termination 上挣扎。StudentModel 初始化时，variables 的掌握估计较高（p = 0.82），conditionals 也较高（p = 0.78），但 loops 较低（p = 0.25），iteration patterns 更低（p = 0.15）。
阶段 2——课程选择：CurriculumPlanner 查询 get_mastery_state() 和知识图谱。Loop fundamentals 的先修条件已经满足，variables 和 conditionals 都高于阈值。预期收益启发式将 “for-loop iteration” 排到最高：它处于 Alex 的 ZPD 内，难度 0.45 对应掌握 0.25，delta 在范围内，并且解锁四个下游目标，包括 list comprehensions 和 nested iteration。
阶段 3——互动与 BKT 更新：Alex 收到 “sum even numbers” 练习，并提交正确解法。bkt_update(0.25, True) 返回 0.51，这是显著跃升，但仍低于 0.85 掌握阈值。下一道练习要求 early break condition，产生错误提交。bkt_update(0.51, False) 将估计降至 0.42。智能体将其分类为真实缺口，而不是 slip，因为错误是结构性的，并选择一个诊断追踪问题。
阶段 4——反馈与脚手架：FeedbackGenerator 通过规则第一阶段检测到控制流误解（break placement）。它生成 Level 2 提示：“Your loop logic is sound for the filtering case. Look at where the break executes relative to the accumulation step.” Alex 修正提交。bkt_update(0.42, True) 将掌握提高到 0.62。
阶段 5——间隔重复：两天后，SpacedRepetitionScheduler 将 “for-loop iteration” 标记为到期复习，间隔由 SM-2 算法根据质量分数 3 计算，反映这是提示辅助成功。Alex 在无提示情况下正确完成一次提取练习。掌握上升到 0.79。调度器将下一次复习间隔延长到五天。再一次成功提取后，掌握跨过 0.85，课程规划器将 Alex 推进到 nested iteration patterns。
教育智能体展示出：教学是一个可以通过可处理架构解决的工程问题。学生模型追踪潜在掌握，课程规划器选择高收益目标，间隔重复调度器优化长期保持，反馈生成器针对具体误解。每个组件都通过显式状态更新连接到下一个组件，使智能体的教学推理可审计、可改进。下一节会从个体教学转向一个根本不同的挑战：协调多个智能体，产生超过任何单个推理者能力的集体智能。
集体智能体
上一节考察了单个智能体如何为个体学习者个性化教学。现在我们转向一个根本不同的挑战：多个智能体，每个都拥有部分知识和专门能力，如何协作解决超出任何单个个体能力的问题。本节分三个阶段展开架构：组织团队的多智能体协作模式、聚合竞争性提案的共识机制，以及解释群体层能力如何从个体交互中产生的涌现智能框架。
集体智能体不是一个单一智能体。它是一种组织智能体团队的架构模式，使它们共同推理、辩论替代方案，并通过结构化共识收敛到解决方案。该模式借鉴多智能体系统研究、群体智能、集成方法和群体决策社会科学。核心洞察是：多样化视角结合有效聚合机制，会稳定地产生优于单个推理者的结果，即使该单个推理者能力很强。
理论骨架是 Condorcet Jury Theorem，即孔多塞陪审团定理。如果每个智能体独立得出正确答案的概率为 p > 0.5，那么随着群体规模增长，多数投票得到正确答案的概率会趋近于 1。这是一个强有力结果，但它依赖一个关键假设：独立性。共享相同底层模型的 LLM 智能体可能出现相关错误，违反这一假设。下面描述的多样化机制，正是为了降低这种相关性，让系统更接近 Condorcet 保证成立的条件。
多智能体协作架构
该架构必须回答三个设计问题。智能体如何组织：平级同伴，还是带协调者的层级结构？它们如何通信：通过中心总线，还是成对对话？贡献如何组合：投票、平均、辩论，还是其他方式？
图 15.2 展示了这样一种架构。该图显示四个专门智能体在 facilitator agent 指挥下，通过共享状态仓库协调。
图 15.2——多智能体协作架构
图 15.2 展示四个专门智能体通过共享状态仓库协调：
- 管理协议的 facilitator agent
- 检索外部知识的 research agent
- 整合部分解决方案的 synthesis agent
- 根据定义标准评估质量的 evaluation agent
下面描述的 CollaborativeAgent 类实现协作的核心单元：一个角色专门化参与者，既可以贡献提案，也可以批评他人的提案。这种双重能力将一组独立 LLM 调用，转化为一个可问责的审议过程。
首先，CollaborativeAgent 类定义了多智能体系统中的角色专门化参与者。构造函数接入五项运行时身份和能力：稳定 agent identifier、声明角色、专业画像、LLM client 和 toolset。它还附加 AgentMemory，这是智能体在多个轮次之间保留自身先前推理和交互的本地工作记忆。
class CollaborativeAgent:
def __init__(self, agent_id: str, role: str,
expertise: list[str], llm_client,
tools: list[Tool]):
self.id = agent_id
self.role = role
self.expertise = expertise
self.llm = llm_client
self.tools = tools
self.memory = AgentMemory()
接下来，propose_solution() 方法是“贡献”路径。它接收一个 Problem 和一个 SharedContext。它不是从空白提示开始，而是使用智能体的专业标签，从共享上下文中拉取 relevant_history。这一选择在架构上很重要。它防止智能体重新争论整个对话，并鼓励其专业化，让它对已有提案作出反应，而不是重复生成类似内容。随后，提示要求给出一个方案，并显式说明假设和不确定性，这是一个轻量但重要的保护措施。它强制提案自带 caveats，让后续评估更有意义。该方法返回一个有意结构化的 Proposal 对象。它包含 agent ID、内容，以及两个元数据字段：内部置信度估计和相关性分数。这些字段不只是装饰。它们是下游编排逻辑的原材料，例如共识排序、加权投票或升级规则。最后一行 context.add_proposal(proposal)，则把个体想法转化为共享审议状态。
def propose_solution(self, problem: Problem,
context: SharedContext
) -> Proposal:
"""Generate a solution proposal informed by
the agent's expertise and shared context."""
relevant_history = context.get_relevant(
self.expertise
)
prompt = f"""You are a {self.role} with expertise
in {', '.join(self.expertise)}.
Problem: {problem.description}
Previous proposals from other agents:
{relevant_history}
Based on your expertise, propose a solution.
Explain your reasoning and identify any
assumptions or uncertainties."""
response = self.llm.generate(prompt)
proposal = Proposal(
agent_id=self.id,
content=response,
confidence=self._assess_confidence(
problem, response
),
expertise_relevance=self._compute_relevance(
problem
)
)
context.add_proposal(proposal)
return proposal
第二个方法 evaluate_proposal() 是“批评”路径。它要求智能体从四个维度评估另一个智能体的提案：正确性、完整性、可行性，以及风险或缺口，并为每个维度从 0 到 10 打分。输出被封装为 Evaluation 对象，包含结构化分数和解释性批评。在实践中，这正是系统避免多智能体设计中常见失败的方式：只收集多个意见，却没有一致评估标准。共享评分 schema 让系统能够跨智能体比较评估，并检测 outlier。
def evaluate_proposal(self, proposal: Proposal,
problem: Problem) -> Evaluation:
"""Evaluate another agent's proposal from this
agent's area of expertise."""
prompt = f"""You are a {self.role}. Evaluate
the following proposal for solving:
{problem.description}
Proposal by {proposal.agent_id}:
{proposal.content}
Assess: correctness, completeness, feasibility,
and any risks or gaps from your perspective.
Score each dimension from 0 to 10."""
response = self.llm.generate(prompt)
return Evaluation(
evaluator_id=self.id,
proposal_id=proposal.id,
scores=self._parse_scores(response),
critique=response
)
上面的代码捕获了让集体智能成为一种架构模式，而不是修辞声明所需的最小机制。系统不会把“多个智能体”当成“正确性”的同义词。它创建了一个可重复的提案生成和同行评审循环，其中每个智能体输出都会成为共享状态，每个提案都可以基于一致量规被挑战。
在使用中，这种模式特别适合教育相关场景，例如课程设计、课程审计和评分量规创建。在这些场景中，目标不是单一答案，而是一个可辩护的综合方案。一个 lead “instructor” agent 可以要求教学法专家批评认知负荷，领域专家验证技术准确性，评估专家检查任务是否真正测量预期目标。编排层随后可以使用结构化置信度和评分信号聚合提案，浮现分歧以供解决，并保留完整审议 trace 作为审计 artifact。这个 trace 让系统可教学、可治理：它让教师不仅看见最终决定是什么，也看见为什么竞争性替代方案被拒绝。
共识机制与投票系统
面对来自不同专业背景、不同置信水平的智能体提案，系统如何确定最佳集体答案？该智能体实现一个分层共识机制，分三个阶段运行：独立提案、交叉评估和综合。
评估阶段使用加权投票，每个智能体的影响力与其展示出的领域专业性成比例。提案 p_j 的共识分数为：
Score(p_j) = Σ_i [ w_i · relevance_i · score_ij ]
其中，w_i 是智能体 i 的专业权重，relevance_i 衡量智能体 i 的专业性与问题的相关程度，score_ij 是智能体 i 对提案 j 的评估分数。专业权重通过指数移动平均更新，在历史表现与近期准确性之间取得平衡。
这种聚合规则满足社会选择理论中的理想属性：Pareto efficiency，即普遍偏好会被尊重；dictator-freeness，即当没有单个智能体权重超过其他所有智能体权重之和时，没有独裁者。Arrow 不可能性定理在一定程度上被绕开，因为系统使用的是 cardinal evaluations，即数值评分，而不是 ordinal rankings，即序排名。
在平衡通信下，智能体提案会以指数速度收敛到共识。实践启示是：防止任何单个智能体主导，不仅能减少偏见，还能加速收敛，从而为专业校准机制提供理论理由。
图 15.3 从独立提案开始，经过批评—评分循环，到最终综合结果，追踪这一流动，展示共识机制如何跨多轮收敛。
图 15.3——共识与投票机制
图 15.3 追踪了从独立提案，到交叉评估、加权评分和综合输出的流程。被拒绝元素会随解释一起记录，创建透明审计轨迹，支持第 12 章中的可解释性要求。
该系统防范已知群体决策失败：
防止群体思维：每轮评估中至少有一个智能体被分配 adversarial critic 角色，负责无论表面共识如何都要识别弱点。该角色会轮换；在生产中，启用主动批评者的轮次，在风险识别上的综合评分高出 12%。
缓解锚定偏差：智能体看到提案的顺序会被随机化。
专业校准：相关性分数会门控每个智能体的投票权重，防止其在自身领域之外拥有过度影响力。
下面的 ConsensusEngine 类实现编排层，将多个提案转化为决策。它不是选择第一个看似合理的回应，而是运行一个有界多轮协议：智能体互相批评提案，分数按专业权重聚合，提案被反复优化直到收敛。
class ConsensusEngine:
def __init__(self, agents: list[CollaborativeAgent]):
self.agents = agents
self.expertise_weights = {
a.id: 1.0 for a in agents
}
构造函数用相等专业权重初始化每个智能体。这是一个有意设计选择：它让权重显式且可调，而不是隐含在提示措辞中。在生产中，权重通常由角色权威或长期测量到的可靠性驱动。下一段实现多轮共识协议。
def run_consensus(self, problem: Problem,
max_rounds: int = 3
) -> ConsensusResult:
"""Execute multi-round consensus protocol with
convergence detection and early termination."""
context = SharedContext()
proposals = []
for agent in self.agents:
proposal = agent.propose_solution(
problem, context
)
proposals.append(proposal)
第一阶段启动流程：每个智能体基于共享上下文生成独立提案，共享上下文会累积先前贡献，使后续智能体能避免重复。有了提案之后，该方法进入下面的批评与优化循环。每一轮中，一个智能体被指定为 adversarial critic，用于压力测试提案。每个智能体都会评估其他智能体的每个提案，生成带评分的批评。如果分数在容忍阈值内收敛，引擎就综合出最终结果并提前终止；否则，提案被优化，循环继续。
best_result = None
for round_num in range(max_rounds):
critic_idx = round_num % len(self.agents)
self.agents[critic_idx].set_role(
"adversarial_critic"
)
evaluations = []
for agent in self.agents:
for proposal in proposals:
if proposal.agent_id != agent.id:
evaluation = agent.evaluate_proposal(
proposal, problem
)
evaluations.append(evaluation)
scores = self._compute_consensus_scores(
proposals, evaluations
)
if self._has_converged(scores, tolerance=0.5):
best_result = self._synthesize(
proposals, evaluations, scores
)
break
proposals = self._refine_proposals(
proposals, evaluations, context
)
self.agents[critic_idx].reset_role()
if best_result is None:
best_result = self._synthesize(
proposals, evaluations, scores
)
return best_result
最后一段处理分数聚合。每个提案都会基于评估获得一个专业加权共识分数。按专业权重加权，确保安全审查员对安全敏感提案的批评，比通才批评拥有更高权重。这些权重也可以成为学习杠杆：如果系统观察到某些角色总能捕获错误，就可以随时间提高其权重。
def _compute_consensus_scores(self, proposals,
evaluations
) -> dict[str, float]:
"""Compute expertise-weighted consensus scores."""
scores = {}
for proposal in proposals:
relevant_evals = [
e for e in evaluations
if e.proposal_id == proposal.id
]
weighted_sum = sum(
self.expertise_weights[e.evaluator_id]
* e.scores.get("overall", 5.0)
for e in relevant_evals
)
total_weight = sum(
self.expertise_weights[e.evaluator_id]
for e in relevant_evals
)
scores[proposal.id] = (
weighted_sum / total_weight
if total_weight > 0 else 0.0
)
return scores
ConsensusEngine 是多智能体协作的轻量编排层。其构造函数接收一组 CollaborativeAgent 实例，并初始化 expertise_weights map。这是一个重要设计选择：它让“谁的批评更重要”变得显式且可调，而不是隐藏在提示措辞中。在生产中，这些权重通常由角色权威（例如安全审查员 > 通才）或长期可靠性测量驱动。
run_consensus() 方法实现一个三阶段多轮协议。
提案生成（第 0 轮启动） ：创建新的 SharedContext，每个智能体使用 propose_solution() 生成初始提案。共享上下文累积这些提案，使后续智能体能够看到之前工作并避免重复。
批评与评分（迭代轮次） ：每一轮中，都会通过 critic_idx = round_num % len(self.agents) 将一个智能体轮换为 adversarial critic 角色。这确保每一轮至少有一位刻意怀疑的审查者，而不是一群只会友好总结的智能体。随后，引擎通过让每个智能体评估不是自己提出的提案，收集 Evaluation 对象。这对问责很重要：它防止智能体自我评分，并强制交叉检查。
评估通过 _compute_consensus_scores() 聚合，该方法为每个提案计算评估者 “overall” 分数的专业加权平均。计算很直接：weight × score 之和除以总权重。如果没有相关评估，该提案获得 0.0，这是一个清晰信号，表示系统缺少覆盖，而不是静默默认值。
收敛检测与优化：评分后，_has_converged(scores, tolerance=0.5) 判断群体是否达到稳定。这里的收敛意味着分数分布不再有明显移动，因此更多轮次不太可能增加价值。如果达到收敛，_synthesize() 会生成最终 ConsensusResult，将最佳提案与支持性批评和评分理由合并。如果尚未收敛，_refine_proposals() 会基于批评生成新提案集，循环继续，并受 max_rounds 限制。
最后，如果协议达到轮次限制仍未收敛，它仍会通过综合最新提案和评估返回结果。这是生产思维细节：系统被设计为有界且可预测，而不是开放式无止境。
这个共识引擎将协作形式化为一个带明确停止条件的受控运行时过程。其教育相关性很实际。在课程设计、教案规划或评估创建中，团队很少需要单个视角给出的单一“最佳”答案。他们需要一个能经受多个镜头批评的方案，包括教学法、领域正确性和评估有效性。这里展示的多轮循环就是 agentic 系统近似该审查过程的方式：一个智能体提出方案，其他智能体挑战它，然后该方案被优化，直到群体评分稳定。收敛检查不只是优化手段。它是治理机制，既限制审议成本，又确保系统至少尝试过对抗性审查。随着时间推移，专业权重也可以成为学习杠杆。如果系统观察到某些角色持续捕获错误或预测下游失败，就可以提高它们权重，使共识更偏向可靠批评，而无需重写协议。
案例研究：通过协作共识进行多智能体评分量规设计
为了看到这些组件如何运行，考虑一个具体场景：三个智能体协作设计一份入门编程作业的评分量规。作业要求学生实现一个合并两个已排序列表的函数。教学法智能体、领域专家智能体和评估智能体分别带来不同视角。
使用上面定义的 CollaborativeAgent 类，每个智能体都被初始化为不同角色和专业列表。教学法智能体的专业覆盖脚手架、认知负荷和形成性反馈。领域专家智能体专注算法正确性、边界案例和代码风格。评估智能体关注评分量规有效性、评分者间一致性和成绩分布。
第一轮中，每个智能体针对共享上下文调用 propose_solution()。教学法智能体提出一个偏向过程的量规：40% 用于展示清晰的问题解决策略，30% 用于正确性，30% 用于代码可读性。领域专家提出一个偏向技术严谨性的量规：50% 正确性（包括空列表和重复元素等边界案例），30% 效率，20% 风格。评估智能体提出一个优化评分可靠性的量规：五个二元标准（处理空输入、保持排序、运行复杂度 O(n)、不使用内置 sort、包含 docstring），以减少主观判断。
随后 ConsensusEngine 进入批评—优化循环。在评估阶段，教学法智能体批评领域专家量规忽略过程，并惩罚那些正确但非最优的解法。领域专家批评评估智能体的二元标准缺少部分分。评估智能体批评教学法智能体的量规依赖主观的“问题解决策略”判断，降低评分者间一致性。
经过一轮优化后，提案收敛到一个混合量规：五个具体标准（来自评估智能体），每项采用三分制（缺失、部分、完整），而非二元制（来自教学法智能体对部分分的强调），并且其中两个标准显式测试边界案例（来自领域专家）。共识分数稳定在 0.5 容忍阈值内，引擎综合出最终评分量规。
这个例子展示了集体架构的两个合理性。第一，最终量规在质量上不同于任何单个智能体提案：它结合了评估可靠性、教学细腻度和技术覆盖，而没有任何单个智能体一开始同时优先考虑这些。第二，批评阶段浮现了真实权衡（过程 vs. 可靠性，部分分 vs. 评分速度），这些权衡在单智能体设计中会保持隐含。结构化共识循环让这些权衡被显式化、辩论并解决。
上面的叙述用文字追踪了量规设计过程。下面的代码让同一场景可运行。它使用 worked example 中的角色提示实例化三个 CollaborativeAgent，将它们传入 ConsensusEngine，并执行完整提案—批评—优化循环。一个 mock LLM client 代替语言模型，使读者可以本地运行代码，并替换为自己的 provider。
# Runnable CI case study: rubric design consensus
from typing import Callable
def mock_llm(prompt: str) -> str:
"""Substitute with an actual LLM client."""
return f"[Response to: {prompt[:80]}...]"
# 1. Instantiate role-specialized agents
pedagogy = CollaborativeAgent(
role="Pedagogy Specialist",
expertise=["scaffolding", "cognitive load",
"formative feedback"],
llm_client=mock_llm
)
domain = CollaborativeAgent(
role="Domain Expert",
expertise=["algorithm correctness",
"edge cases", "code style"],
llm_client=mock_llm
)
assessment = CollaborativeAgent(
role="Assessment Specialist",
expertise=["rubric validity",
"inter-rater reliability",
"grade distribution"],
llm_client=mock_llm
)
# 2. Build the consensus engine
engine = ConsensusEngine(
agents=[pedagogy, domain, assessment]
)
# 3. Define the shared problem context
context = (
"Design a grading rubric for an introductory "
"programming assignment: implement a function "
"that merges two sorted lists."
)
# 4. Run the consensus session
result = engine.run_session(context)
# 5. Inspect the output
print(f"Rounds: {result['rounds']}")
print(f"Final score: {result['consensus_score']:.2f}")
print(f"Rubric:\n{result['final_proposal']}")
run_session() 调用会执行前面几个部分描述的完整共识循环：每个智能体提出初始量规，引擎收集加权批评，智能体优化提案，循环重复直到共识分数超过收敛阈值。final_proposal 字段包含综合后的量规。使用真实 LLM client 时，读者会看到叙述中描述的同样收敛模式：来自评估智能体的二元标准、来自教学法智能体的部分分尺度，以及来自领域专家的边界案例覆盖，会合并成单一混合工具。
涌现智能框架
集体智能最引人注目的方面不是聚合，而是 emergence，也就是涌现：由智能体互动产生、任何单个智能体无法独立生成的解决方案。从信息论角度看，涌现可以通过 synergistic information，即协同信息来刻画：集体输出中依赖智能体输入之间互动、且不能还原为个体贡献的部分。
该架构通过三种机制支持涌现：
Cross-pollination prompting，交叉授粉式提示：这会在优化期间让每个智能体接触竞争提案中的最强元素，触发新组合。在每轮优化中，ConsensusEngine 会将每个提案中最高分元素分享给所有智能体。因此，教学法智能体会看到领域专家的边界案例标准，反之亦然。在量规设计场景中，这个机制使教学法智能体采纳了评估智能体的二元标准结构，同时保留自身部分分评分，而这个组合既不是任何单个智能体独立提出的。
Constraint relaxation，约束放松：这受 TRIZ 理论启发。TRIZ 是俄语 Teoriya Resheniya Izobreatatelskikh Zadatch 的缩写，翻译为 Theory of Inventive Problem Solving，即发明问题解决理论。当共识停滞时，facilitator 会系统性放松问题约束，迫使智能体质疑未经检查的假设。例如，如果三个智能体在量规应优先考虑正确性还是过程上僵持，facilitator 会暂时移除“单一量规”约束，允许智能体为形成性和总结性场景探索不同量规。由此产生的设计往往会揭示共享标准，从而打破原始僵局。
Analogical transfer，类比迁移：这包括引入 immediate domain 之外具备专业知识的智能体。一个熟悉生物系统的智能体，可能将 redundancy、self-healing 或 evolutionary adaptation 概念引入软件架构讨论。在教育语境中，一个基于临床诊断推理训练的智能体，可能将误解检测重构为 differential diagnosis，即列出候选误解、排序区分性问题，并排除假设。由此产生的协议，会给教育专家智能体提供一个结构化诊断工作流，而该工作流单靠教学文献可能不会产生。
一个具体示例：在课程设计任务中，教学法智能体提出一条线性先修链来教授递归。认知科学智能体基于 worked-example 研究，建议穿插递归和迭代解法，让学生建立比较性心理模型。软件工程智能体补充说，真实代码库很少将递归和迭代孤立开来，因此从实践相关性角度支持这种交错方法。没有单个智能体会独立综合出这一理由；领域特定约束的组合产生了一个课程结构，在模拟评估中优于每个智能体单独提案。这就是实践中的协同信息：集体输出依赖智能体视角之间的互动，而不只是它们的简单相加。
Facilitator 通过监控提案之间的语义距离，在多样性和连贯性之间取得平衡。收敛过快会触发扰动，让一个智能体探索刻意非常规方案。分散过大则会触发围绕局部共识区域的聚焦讨论。
这些涌现机制并不是推测性附加项，而是集体方法值得支付协调开销的架构原因。一个只是平均独立答案的智能体系统，只能带来适度增益。一个主动工程化协同条件的系统，也就是多样化视角、结构化批评和有意约束放松，会产生单个智能体无法达到的解决方案，让集体真正大于部分之和。
小结
本章探索了构建会教学、会学习、会迁移知识的智能体的两种互补方法。
教育智能体结合知识图谱课程、BKT 和基于认知科学的自适应技术，创建个性化学习系统。编程导师案例研究展示了这些组件在生产中的运行：两阶段误解检测器、上下文感知反馈和间隔重复调度，使评估分数提升 34%，并将课程完成率从 71% 提升到 89%。
集体智能体将多智能体协作扩展为共识驱动的问题解决。带专业校准的加权投票、防止群体思维的对抗性批评者，以及用于涌现洞察的交叉授粉，产生了持续优于单智能体输出的综合设计。最有价值的结果来自具备互补专业知识的智能体之间的协同互动。在量规设计 worked example 中，一个三智能体团队，即教学法、领域专家、评估，收敛到一个混合评估工具，结合了评估智能体的二元标准可靠性、教学法智能体的部分分细腻度，以及领域专家的边界案例覆盖，而这些没有任何单个智能体独立产生。
这两种架构共同说明了一个反复出现的原则：最强大的智能体系统，会将深度领域专业化与系统性反馈循环和协作推理结合起来。无论是在教一个学生，还是解决一个设计问题，该模式都成立：感知当前状态，推理最佳下一步，采取行动，观察结果，并学习。教育与知识智能体将这一模式应用到一个领域：在这里，成功不是以智能体自身表现来衡量，而是以它所服务的人类成长来衡量。
下一章中，我们将探索连接数字智能与物理世界的智能体：具身智能体。它们会围绕物理环境进行推理，协调机器人系统，并将传感器数据与认知架构集成起来。
