多智能体系统真正进入生产环境后，难点不再只是“让几个 Agent 相互调用”，而是如何控制执行路径、稳定评估线索、限制成本，并确保生成的销售邮件有依据、可审计。Thrad.ai 的实践覆盖了从潜在客户发现到个性化邮件生成的完整流程，并对 Strands Agents 中的 Swarm 与 Graph 两种编排方式进行了延迟、成本和邮件质量的正面对比。
来源摘要没有给出具体基准数字或最终胜者，因此本文不会虚构结论，而是拆解这两种模式的工程差异，并给出一套可以直接运行和改造的线索评分示例。
把销售流程拆成职责明确的 Agent
一条可控的自动化流水线通常可以拆成以下角色：
- Discovery Agent：从允许的数据源发现候选公司与联系人。
- Enrichment Agent：补充行业、公司规模、职位、近期事件等信息。
- Intent Agent：判断候选对象是否表现出采购、扩张、招聘或技术迁移意图。
- Scoring Agent：按照权重、意图类别和时间衰减计算分数。
- Writer Agent：基于已验证的事实生成个性化邮件。
- Reviewer Agent：检查事实引用、敏感表达、重复内容和发送策略。
这种拆分的价值不是让 Agent 数量更多，而是为每个阶段建立清晰的输入、输出和失败边界。例如，Writer Agent 不应自行补全未知的公司动态；如果 Enrichment Agent 没有提供证据，邮件就不应该把推测写成事实。
一个适合跨 Agent 传递的线索对象可以约定为：
{
"prospect_id": "p-1042",
"company": "Example Robotics",
"contact_role": "VP Engineering",
"signals": [
{
"type": "hiring_growth",
"strength": 0.8,
"observed_at": "2025-02-15",
"evidence": "Engineering openings increased from 8 to 21"
}
],
"score": null,
"email_draft": null
}
evidence 字段非常关键。它既能约束邮件生成，也能支持人工复核和事后审计。
Swarm 与 Graph：选择自由协作还是显式路径
Swarm 模式让智能体根据任务和上下文动态移交工作。它适合探索性强、执行路径难以预先穷举的任务，例如发现新线索后，由不同专家 Agent 自主判断是否需要补充行业信息、招聘数据或技术栈信号。
它的代价是执行路径更难预测。动态移交可能增加模型调用次数、上下文长度和尾部延迟，也让复现某次运行变得更困难。因此，评测时不能只看平均延迟，还应记录 P95 延迟、每条合格线索的成本、移交次数和无效循环率。
Graph 模式把节点和边显式定义出来，例如：
Discover -> Enrich -> Classify Intent -> Score
|-> Reject
|-> Write -> Review -> Approve
Graph 更适合存在硬性业务规则的流程。低分线索可以在评分节点后立即停止；缺少证据的邮件可以退回 enrichment 节点；审核失败的内容不能直接进入发送队列。代价是流程需要提前设计，遇到未覆盖的新情形时灵活性较低。
两种模式不必二选一。可以这样实践：外层使用 Graph 固定合规边界和预算，某个 enrichment 节点内部再使用小型 Swarm 探索不同数据源。这样既保留动态协作能力，又不会让整个生产流程失去控制。
可运行的线索评分：权重、意图与时间衰减
来源提到的评分机制包含加权标准、意图分类和时间衰减。下面是一个只依赖 Python 标准库的最小实现。示例假设信号强度位于 0.0 到 1.0，并采用指数衰减；实际权重和半衰期应通过历史转化数据校准。
将代码保存为 score_prospect.py，直接运行 python score_prospect.py：
from dataclasses import dataclass
from datetime import datetime, timezone
from math import exp
@dataclass(frozen=True)
class Signal:
kind: str
strength: float
observed_at: datetime
WEIGHTS = {
"pricing_visit": 1.00,
"product_comparison": 0.90,
"hiring_growth": 0.65,
"funding_event": 0.55,
"general_news": 0.20,
}
INTENT_MULTIPLIERS = {
"high": 1.20,
"medium": 1.00,
"low": 0.70,
"unknown": 0.40,
}
def temporal_decay(age_days: float, half_life_days: float = 30.0) -> float:
"""Return 0.5 after one half-life and continue decaying exponentially."""
return exp(-0.693147 * max(age_days, 0.0) / half_life_days)
def score_prospect(signals: list[Signal], intent: str, now: datetime) -> float:
raw_score = 0.0
for signal in signals:
weight = WEIGHTS.get(signal.kind, 0.0)
strength = min(max(signal.strength, 0.0), 1.0)
age_days = (now - signal.observed_at).total_seconds() / 86400
raw_score += weight * strength * temporal_decay(age_days)
multiplier = INTENT_MULTIPLIERS.get(intent, INTENT_MULTIPLIERS["unknown"])
return round(min(raw_score * multiplier * 100, 100.0), 2)
if __name__ == "__main__":
now = datetime(2025, 3, 1, tzinfo=timezone.utc)
signals = [
Signal("pricing_visit", 0.9, datetime(2025, 2, 27, tzinfo=timezone.utc)),
Signal("hiring_growth", 0.8, datetime(2025, 1, 20, tzinfo=timezone.utc)),
Signal("general_news", 0.6, datetime(2024, 11, 1, tzinfo=timezone.utc)),
]
score = score_prospect(signals, intent="high", now=now)
decision = "write_email" if score >= 60 else "manual_review" if score >= 35 else "reject"
print({"score": score, "decision": decision})
这里有三个值得保留的设计：未知信号默认权重为零，过期信号自动降权，最终分数有明确上限。生产系统还应输出每个信号的分数贡献，避免 Scoring Agent 只返回一个无法解释的数字。
Writer Agent 的提示词也应只允许使用结构化证据。可以这样设计：
你是 B2B 邮件撰写 Agent。
只允许使用 <prospect> 中出现的事实，不得推测收入、预算、技术栈或采购计划。
邮件正文不超过 120 个中文字符，包含一个具体事实和一个低承诺度行动请求。
如果 evidence 为空，返回：{"status":"insufficient_evidence"}。
输出严格 JSON：{"subject":"...","body":"...","evidence_ids":["..."]}。
<prospect>
{{PROSPECT_JSON}}
</prospect>
基准测试不能只比较“生成得快不快”
Swarm 与 Graph 的正面对比至少应使用同一批冻结线索、同一模型配置、相同重试策略和相同质量评分标准。否则，延迟、成本和质量数据没有可比性。
建议记录以下指标：
| 维度 | 指标 |
|---|---|
| 延迟 | 中位数、P95、每个阶段耗时 |
| 成本 | 每条输入线索成本、每条合格线索成本、无效调用成本 |
| 质量 | 事实准确率、个性化程度、行动请求清晰度、人工接受率 |
| 稳定性 | 超时率、重试率、循环移交率、结构化输出解析失败率 |
| 业务结果 | 回复率、正向回复率、退订率和投诉率 |
邮件质量最好采用盲评，并把“事实正确”设为硬门槛。措辞流畅但引用了不存在的融资、招聘或产品信息，不能算高质量输出。
上线前必须补齐治理边界
生产部署不能只依赖提示词约束。治理控制应覆盖数据、工具、模型调用和发送动作：
- 为每个 Agent 配置最小权限，写邮件的 Agent 不应拥有直接发送权限。
- 对调用次数、令牌、总成本和执行时间设置硬预算。
- 保存 Agent 版本、提示词版本、模型版本、输入证据和工具调用记录。
- 对外部文本进行提示注入隔离，不把网页内容当作系统指令执行。
- 在发送前执行事实检查、敏感内容检查、重复联系人检查和退订名单检查。
- 对高价值账户、低置信度分类和异常分数强制人工审批。
- 对个人数据设置保留期限，并遵守适用的隐私和商业通信规则。
落地时，建议先用 Graph 固定发现、评分、审核和批准节点，再把范围明确的研究任务交给 Swarm。使用真实历史线索离线回放，分别测量延迟、成本和邮件接受率；只有当新增动态协作确实提高质量或覆盖率时，才值得承担额外复杂度。多智能体架构的目标不是让 Agent 自由行动，而是让每一次自动决策都能解释、限制和复现。