Part I Setting the Scene

为什么必须先冻结联合模型

先说明多智能体系统解决什么问题、如何看待自治，以及何时不该使用代理抽象。 第一部分把自治计算、软件工程范式与社会模拟三种视角并列，要求从环境、控制权和交互依赖证明代理建模有必要。 本页不以单个代理“看起来聪明”为通过条件，而是检查联合状态、偏离动机、失败传播和可重放证据。

直觉、对象与计算合同

贯穿场景是：判断一组微服务是否真的构成多智能体系统。参与者、可观察信息、行动集、偏好或目标、环境转移、协议版本和终止条件必须在运行前固定，不能在看到结果后修改效用或阈值。

$$agent_fit = autonomy + situated_action + interaction_dependence$$

公式用于公开关系与前提，不替代正式证明或实证测量。若组件行为完全由中央程序决定且没有局部选择，代理抽象通常只增加术语。 本页重点防范：把普通对象重命名为代理，却没有独立目标、局部观察或行为控制权。

、、、、、

正式目录节点：解释与联合验证

下列目录节点逐项映射到解释、页面专属实验和章末答案。每个节点都必须指出它改变哪个联合状态以及什么观测会推翻结论；单纯出现术语不计覆盖。

Part I Setting the Scene

“Part I Setting the Scene”细化本单元的正式问题，需要映射到参与者、信息、行动、结果和失败边界。 在“第一部分把自治计算、软件工程范式与社会模拟三种视角并列，要求从环境、控制权和交互依赖证明代理建模有必要。”这条联合因果链中，本节点重点检查自治；只改变一个条件并保存联合轨迹，若出现“把普通对象重命名为代理，却没有独立目标、局部观察或行为控制权”，就在首个分叉停止。

常见误区

术语

练习与答案

本章小结

Part I Setting the Scene 通过 界定环境、识别自治、列出交互、比较对象、决定建模 把 自治、环境、目标、依赖、适用性 连接为可计算、可反驳的联合证据链。最终验收是：能为采用和拒绝代理方案分别给出可观察证据。

前后导航

• 上一页：Preface
• 下一页：Chapter 1 Introduction