市场调研团队

📄← 模块索引↗ · 📄↑ 总索引↗

完成本节后，你应当能够：

• 解释市场调研团队对智能体系统的贡献。
• 判断何时该使用它、何时更简单的设计就已足够。
• 将该模式实现为可观察、可测试的组件。
• 识别其主要的成本、安全与可靠性风险。

对于需要证据、分析、可视化与叙述文字的研究交付物，使用专家团队协作。

清晰的产出物契约能让各位专家并行工作，同时由管理者维护整体的一致性与来源可追溯性。

箭头表示控制流与数据流的走向，不一定对应不同的模型。图中的方框可以由一个确定性函数、被多次调用的同一个模型，或多个不同模型来实现。在整个流程中应保留追踪标识符（trace identifiers）。

1. 管理者定义研究问题与交付物的评分标准。 在实现之前，先写清楚输入、预期输出、负责人和失败条件。
2. 研究员收集证据并进行排序。 让这一决策在日志或结构化状态中可被观察，以便后续评估。
3. 分析师综合归纳论断与不确定性。 在此边界处应用最小权限原则，并验证相关假设。
4. 设计师制作指定的可视化内容。 记录结果以及足够复现或诊断所需的元数据。
5. 撰写者完成叙述文字。 在继续之前，将结果与明确的验收标准进行比较。
6. 编辑核查一致性与引用。 依据既定策略，将失败情形导向重试、回退方案，或人工审核。
7. 管理者验收或要求修订。 把观察到的行为加入回归测试集与运维记录中。

• 状态（State）： 在结构化的运行记录中保存消息、工具调用、观察结果、产出物、决策理由、尝试次数、token 用量、延迟以及最终状态。
• 契约（Contracts）： 为每个组件定义带类型的输入、带类型的输出、允许的副作用、超时时间和错误类别。
• 控制（Controls）： 使用最小权限凭证、白名单工具、有界循环、输入校验、输出校验，并为有实际影响的动作设置审批关卡。
• 可观测性（Observability）： 在符合隐私规则的前提下，记录 prompt 或其版本、模型与参数、工具参数、工具结果、异常、时间戳和成本。
• 评估（Evaluation）： 测试具有代表性的案例、边界案例、对抗性案例和失败恢复案例，并与最简单可行的基线进行比较。

每位专家都会返回一个包含来源、假设与完成状态的文件或结构化数据。

输入：用户目标 + 约束条件
状态：{run_id, step, observations, budget, status}
决策：下一个有边界的动作
校验：权限、参数与策略
执行：模型调用、确定性代码或工具
观察：结构化结果或分类后的错误
停止：验收标准通过、预算用尽，或转交人工

• 该使用场景确实证明了此模式优于更简单的一次性调用。
• 输入、输出与成功标准都已明确。
• 工具调用及其副作用均已校验并获得相应权限。
• 循环设有硬性预算上限和有意义的停止条件。
• 失败情形会触发安全的重试、回退方案，或转交上报。
• 质量、延迟与成本被一并测量。
• 回归测试中至少包含一个失败案例。

1. 什么样的可观察失败，会表明这一模式被误用了？
2. 哪一部分应当是确定性的，而不应交给 LLM 处理？
3. 每一步所需的最小上下文是什么？
4. 人工审批或上报关卡应设在哪个位置？
5. 哪个指标能证明新增的复杂度是值得的？

为一个范围狭窄的任务实现一个最小可行版本。保存三条轨迹：一次成功的运行、一次可恢复的失败，以及一个必须停止或上报的案例。为每条轨迹编写一个回归测试，并将结果与直接生成的基线进行比较。