本文依据 GitLab services/seleven-mcp 的知识转移文档 docs/calle-agentic-knowledge-transfer.md（事实基线 2026-08-12）整理，是理解 CALL-E Agentic 产品模型的入口。代码级实现细节仍以源码审计页为准。
CALL-E Agentic 不是让一个 Agent 自主打一批电话，而是让系统在可控、可恢复、可审计的边界内，持续拥有并推进一个用户目标。
1. 用户要的不是一通电话，是一个 Goal 被真的完成
Goal 是系统持续负责推进、记录并解释结果的对象——不是「打一通电话」这个动作，也不代表系统保证目标一定达成。
用户说「帮我约周五晚上七点的位子」，Goal 是「周五晚上七点，餐厅有位子」，不是「打一通电话」。约不上时，用户要的是「想办法，并且告诉我进展」。当然，约不上的时候 CALL-E 也可能想不出什么好办法——它没法打开闲鱼帮用户找黄牛订位。所以承诺的是尽力推进和如实告知，不是保证一定约到。
2. 四个「加个功能」引出的运行时
这个决定不是从架构图开始的，是从一串「要不要在 one-shot call 上再加个功能」的讨论开始的：
| 想要的功能 | 在 Agentic 里的天然承载 |
|---|---|
| Playbook（by caller / taxonomy 的电话操作手册） | Skill——今天已有 outbound、inbound、催收三类共 7 个，催收那条是加一个 Skill 目录加出来的，没动 Runtime |
| Knowledge retrieval（退款政策、价目表、FAQ，上传即用） | Artifact——只需告诉 Agent「用户上传了这些」，要用时自己去读 |
| History（上一通打给谁、对方怎么说、试过哪几个时间） | Goal Event / Run / Evidence——唤醒时只带引用；存放已在跑，按需查询仍是草稿 |
| Memory（用户偏好，说过一次不该再问） | 挂在 user 上而不是某个 Goal 上；作用域和失效策略未定，至今一行未做 |
四项单独看都只是「加个功能」，放一起看引出的是同一批问题：存哪？谁决定这次用哪个？跨多次调用怎么保持一致？中间挂了从哪继续？而 one-shot call 的定义恰恰就是「无状态的一次调用」——要把这四件事装进去，就得先给它加一个所有者、一份持久状态、一个调度器和一套恢复机制。做完这些，它已经不是 one-shot 了，只是一个没承认自己是 agent 的 agent。
与其在单次调用上逐个补齐，不如直接建一个本来就拥有这些的运行时。这就是今天的 CALL-E Agentic：一次执行就结束的外呼和长任务 Goal，都跑在同一套 Goal Runtime 上。
3. 术语对齐：「CALL-E」指哪个
- CALL-E v1（Legacy One-shot） —— 旧的无状态实现，3 个 pydantic-ai agent 级联成的固定流水线：planner 定计划 → prompt generator 出话术 → run summary 收尾。每一棒交给下一棒，跑完即止。
- CALL-E —— 今天的 agentic CALL-E，OpenAI Agents SDK 驱动，代码在
calle/agentic。本站文档中的「CALL-E」一律指这个。 - Single-run Outbound Goal —— 当前 Runtime 里一次执行就结束的 Goal。它是一种 Goal，不是 v1 的遗留物。
一次打完的电话这个能力不是被取代，是被吸收了：它今天是 Goal Runtime 里的一种 RunSpec 和 Run，由 outbound-planner 和 voice-agent-run-strategy 产出，跟长任务共用同一套审批、恢复和证据机制。v1 那条独立流水线不再作为独立产品模型存在。建对了运行时，原来的能力不用重写，直接变成它的一个子集。
4. 必须守住的四条用户体验边界
这四条是产品承诺，也是所有评测用例的判据——每写一个 case，都要说得出它验的是哪一条。每条背后都有具体机制，所以「破了哪条」是能指认的，不是感觉问题。
- 系统说的状态是真的。 目标已保存 → 方案已准备 → 方案已验证 → 动作已批准 → 电话已执行 → 结果已确认 → 目标已完成，这七种状态不许互相顶替。反面教材：把「Goal 已创建」说成「事情安排好了」，把「演练通过」说成「电话打成功了」。
- 用户知道系统接下来要做什么。 真实电话、热线绑定之前，用户得知道执行什么、对谁、用哪个版本、一次授权覆盖几个动作、怎么停。反面教材：让另一个 Agent 用自然语言转述一遍要批准的动作。
- 系统没有消失。 长任务里用户要能看到在哪一步、已完成什么、在等什么、为什么需要我输入、下次什么时候继续。反面教材：模型想了三分钟，界面上什么都没有。
- 失败不等于重新开始。 模型出错、进程重启、通话失败、用户暂时离开，都不该让已确认的 Goal、方案和证据消失。反面教材：「刚才那通没打通，麻烦您把餐厅和时间再说一遍」。
四条都是可观察、能写成测试用例的行为——这是它们能当判据的前提。CALL-E 不承诺「更聪明」「更自然」这类验证不了的东西；目前也没有可对外引用的量化基线，任何效果数字都得先建基线。
5. 兑现这四条的代价
当前 CALL-E 包含一套 Goal Runtime、3 个长期 Agent、1 个隔离 Judge，以及 Outbound 和 Inbound 两条主要产品路径；能直接触发真实电话或热线绑定的受保护动作只有两个。兑现四条承诺是有代价的：
- 一次简单外呼也要走完整链路，首次响应比 v1 慢；
- 事实存在 durable state 里，看内容要多一跳读取，Skill 必须写成无状态、每次重读；
- MainAgent 看不见 GoalAgent 的推理，只能靠一条有界摘要；跨 Agent 排障要串事件流；
- Simulation 证据不全一律判「不确定」，会挡住一部分本来没问题的用户。
这些代价为什么认了、当时没选什么、什么条件下该重新评估，在技术架构与框架取舍中有对应的工程视角推演。
接下来进入三条典型产品旅程，看交互式 Outbound、Published Goal 和 Inbound Hotline 如何在同一条主干上分岔。