class: talk cover

<div class="cover-visual" style="background-image: url('../from-kanban-to-execution-agent/images/hero-agent-workbench.png');"></div>
<div class="cover-scrim"></div>
<div class="cover-content">
  <div class="cover-mark"></div>
  <div class="cover-kicker">AI × 订单履行工作台</div>

# 从看板到执行体

<div class="cover-subtitle">
Hermes Agent 驱动的订单履行工作台：让 Agent 读取业务现场、查询履行状态、沉淀关键进展。
  </div>
</div>

<div class="cover-side"><div class="vertical">AGENTIC WORKBENCH</div></div>
<div class="talk-bottom"></div>

---
class: talk

## 我想先从一个普通问题讲起

<div class="opening-question">
  <p class="opening-quote">
    “这个合同/订单最近有没有交单进展？有没有人回复？需要我下一步做什么？”
  </p>
  <p class="talk-lead opening-lead">
这类问题每天都会出现。难点不是写一段总结，而是要把系统状态、消息、邮件和历史进展放在一起看。
  </p>
</div>

<div class="opening-grid">
  <div class="path">
    <div class="node"><b>业务问题</b><span>一个合同/订单<br>一个关注点</span></div>
    <div class="arrow">→</div>
    <div class="node"><b>找事实</b><span>系统、消息、邮件<br>历史进展</span></div>
    <div class="arrow">→</div>
    <div class="node"><b>给判断</b><span>当前结论<br>下一步动作</span></div>
  </div>
  <div class="example">
    <span class="label">这次分享的主线</span>
    <p>我不是想讲“AI 很强”，而是想讲：我们如何把 Agent 接到真实业务现场里。</p>
  </div>
</div>

---
class: talk

## 看板解决了“看见”，但没有完全解决“推进”

<p class="talk-lead">
过去工作台更多是把状态展示出来。Agent 进入之后，工作台可以继续往前一步：帮我找事实、整理判断、准备动作。
</p>

<div class="comparison">
  <div class="pane">
    <span class="big">看板</span>
    <h3>回答“现在是什么状态”</h3>
    <ul class="bullets">
      <li>把合同/订单集中展示出来</li>
      <li>支持筛选、查看、定位问题</li>
      <li>最终仍然依赖人去查消息、问人、记录进展</li>
    </ul>
  </div>
  <div class="pane hot">
    <span class="big">执行体</span>
    <h3>进一步回答“接下来怎么推进”</h3>
    <ul class="bullets">
      <li>能读取沟通上下文和业务状态</li>
      <li>能按流程调用工具查询事实</li>
      <li>能生成进展草稿，等待人确认后写入</li>
    </ul>
  </div>
</div>

---
class: talk

## 所以第一步不是模型，而是让业务现场可读取

<p class="talk-lead">
Agent 能不能做事，取决于它能不能拿到真实上下文。这里的基础能力，比提示词本身更重要。
</p>

<div class="tool-line">
  <div class="tool">
    <span class="tag">沟通</span>
    <b>WeLink CLI</b>
    <span>查询最近消息和邮件，把沟通结论从聊天窗口带进 Agent 上下文。</span>
  </div>
  <div class="tool">
    <span class="tag">业务</span>
    <b>Supply CLI</b>
    <span>查询合同/订单详情，让 Agent 不只靠人转述业务状态。</span>
  </div>
  <div class="tool">
    <span class="tag">进展</span>
    <b>进展 API</b>
    <span>查询历史进展，必要时生成进展草稿并写回系统。</span>
  </div>
  <div class="tool">
    <span class="tag">底表</span>
    <b>Playwright 导出</b>
    <span>批量导出管理批次数据，先把相关合同/订单集中起来。</span>
  </div>
</div>

<div class="example" style="margin-top:28px;">
  <span class="label">一句话</span>
  <p>有了这些入口，Agent 才不是“聪明的写作工具”，而是能接触业务事实的执行助手。</p>
</div>

---
class: talk

## Playwright 批量导出：先把相关合同/订单集中起来

<div class="story-wide">
  <div>
    <p class="talk-lead">
在正式 API 还没有完全打通前，Playwright 解决了一个很实际的问题：自动进入业务系统，把“跟我相关”的管理批次数据导出来。
    </p>
    <p class="talk-lead">
这一步不是 Agent 的全部能力，但它是工作台的底座。没有这张底表，后面的筛选、关注、简报都没有稳定入口。
    </p>
  </div>
  <div class="stack">
    <div class="line-card"><b>进入系统</b><span>自动完成筛选、翻页、导出等重复动作。</span></div>
    <div class="line-card"><b>形成底表</b><span>把页面上的合同/订单数据变成可检索的数据资产。</span></div>
    <div class="line-card"><b>后续替换</b><span>未来可以换成数据库查询或正式 API，上层场景不用重写。</span></div>
  </div>
</div>

---
class: talk

## WeLink CLI 让“最近沟通”可以被 Agent 查询

<div class="story">
  <div>
    <p class="talk-lead">
以前最麻烦的一点是：AI 看不到最近的消息和邮件。人必须复制粘贴，Agent 才知道发生了什么。
    </p>
    <p class="talk-lead">
有了 WeLink CLI，Agent 可以按合同/订单、关键词、时间范围去找沟通上下文。
    </p>
  </div>
  <div class="example">
    <span class="label">它不是简单总结聊天记录</span>
    <p>更重要的是提取“和履行有关的事实”：谁给了新答复、有没有交单承诺、是否出现新的阻塞、需要谁继续确认。</p>
  </div>
</div>

<div class="path">
  <div class="node"><b>消息</b><span>群聊、私聊<br>临时反馈</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>邮件</b><span>正式口径<br>附件信息</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>沟通事实</b><span>责任人、时间<br>结论、缺口</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>履行判断</b><span>能否推进<br>下一步找谁</span></div>
</div>

---
class: talk

## Supply CLI 让合同/订单不再只是页面上的字段

<p class="talk-lead">
合同/订单在这里是同一个业务对象。Agent 要做履行判断，不能只看聊天，还必须回到业务对象本身。
</p>

<div class="story-wide">
  <div class="example">
    <span class="label">Agent 需要知道的不是“一个编号”</span>
    <p>它需要知道这个合同/订单当前在哪个节点、有哪些交付信息、最近有没有状态变化、和哪些进展记录相关。</p>
  </div>
  <div class="stack">
    <div class="line-card"><b>基础信息</b><span>对象是谁，归属哪里，当前要交付什么。</span></div>
    <div class="line-card"><b>履行状态</b><span>当前节点、交付计划、异常或阻塞。</span></div>
    <div class="line-card"><b>关联上下文</b><span>进展记录、风险信息、可能需要补充查询的线索。</span></div>
  </div>
</div>

---
class: talk

## 进展接口让 Agent 的结果沉淀回业务系统

<div class="story">
  <div>
    <p class="talk-lead">
如果 Agent 只是总结一下消息，价值会停在当前对话里。真正进入业务流程，需要把关键结论沉淀成进展。
    </p>
    <p class="talk-lead">
当前可以直接调用原始进展 API。后续更好的方式，是封装进 Supply CLI，统一鉴权、参数、日志和错误处理。
    </p>
  </div>
  <div class="path" style="margin-top:0;">
    <div class="node"><b>查历史</b><span>避免重复记录<br>识别口径冲突</span></div>
    <div class="arrow">→</div>
    <div class="node"><b>生成草稿</b><span>只写事实<br>保留来源</span></div>
    <div class="arrow">→</div>
    <div class="node"><b>确认写入</b><span>人确认后<br>进入正式记录</span></div>
  </div>
</div>

<div class="example" style="margin-top:26px;">
  <span class="label">关键边界</span>
  <p>写入不是静默发生的。Agent 可以准备草稿，但改变业务记录前，需要展示依据并由人确认。</p>
</div>

---
class: talk

## 再看 supply-chrome：它已经不只是一个看板

<p class="talk-lead">
现在的 supply-chrome 已经沉淀了不少“业务现场能力”。这很重要，因为 Agent 接入不是从零开始，而是接到一个已经能操作合同/订单、批次、进展和协同信息的工作台上。
</p>

<div class="cap-grid">
  <div class="cap-card">
    <b>工作台入口</b>
    <span>多 Tab、最近合同、合同列表、命令面板、粘贴识别，能快速定位一组合同/订单。</span>
  </div>
  <div class="cap-card">
    <b>履行数据</b>
    <span>管理批次、本地 IndexedDB、订单清洁树缓存、关联 00E、齐套/交付状态。</span>
  </div>
  <div class="cap-card">
    <b>执行动作</b>
    <span>录进展、批量进展识别、复制催办消息、生成邮件、保存并同步进展。</span>
  </div>
  <div class="cap-card">
    <b>专题视图</b>
    <span>批次、需求清单、订单清洁树、台套概览、协同、异常队列、自定义筛选。</span>
  </div>
</div>

<div class="example" style="margin-top:28px;">
  <span class="label">所以这页要讲清楚</span>
  <p>Agent 不是凭空“接管业务”，它接入的是一个已经有数据、动作、上下文和 UI 反馈的工作台。</p>
</div>

---
class: talk

## supply-chrome 里已经有一条 Agent 接入闭环

<p class="talk-lead">
这不是一个口头方案。当前代码里已经有从工作台到本地 Agent、再回到浏览器数据源的链路。
</p>

<div class="path compact dense">
  <div class="node"><b>工作台</b><span>行操作 /<br>AgentPanel</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>trigger</b><span>trigger<br>BottleneckUrge</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>WS</b><span>runAgentSkill<br>17400</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>Agent</b><span>supply-chrome<br>agent daemon</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>tool_call</b><span>local-data<br>handler</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>数据源</b><span>IndexedDB<br>API/cache</span></div>
</div>

<div class="story-wide" style="margin-top:28px;">
  <div class="example">
    <span class="label">前端不是只等一个答案</span>
    <p>AgentPanel 会把执行过程展示出来：Artifact 在上，Evidence 和 Trace 在下。人能看到它查了什么、结果是什么、哪里异常。</p>
  </div>
  <div class="stack compact">
    <div class="line-card"><b>tool_call</b><span>Agent 要查事实时发起工具调用。</span></div>
    <div class="line-card"><b>tool_result</b><span>浏览器侧从本地数据/API 返回结构化结果。</span></div>
    <div class="line-card"><b>trace</b><span>每一步执行过程回到 UI，便于确认和排错。</span></div>
  </div>
</div>

---
class: talk

## Agent 现在能调用的，是一组本地业务工具

<p class="talk-lead">
这些工具名本身就说明了 Agent 接入的深度：它不是只读一段页面文本，而是可以按合同/订单和批次维度查询业务事实。
</p>

<div class="method-grid">
  <div><b>fetchContractBasic</b><span>确认合同/订单基础信息和当前代表批次状态。</span></div>
  <div><b>listBatchesSummary</b><span>列出合同/订单下的批次、状态、交付日期、处理人。</span></div>
  <div><b>fetchBatchDetail</b><span>查单个批次的 EPD_A、CPD、RPD、APD、关联批次。</span></div>
  <div><b>lookupInCleanTree</b><span>查订单清洁树，识别编码父子关系和需求信息。</span></div>
  <div><b>fetchRelatedContracts</b><span>查关联合同/订单，用于识别上下游影响。</span></div>
  <div><b>getRecipientByRole</b><span>按供应经理、大调度、资源统筹、OFM 解析收件人。</span></div>
  <div><b>rollUpToQuoteCode</b><span>从组件编码上卷到报价编码，便于定位瓶颈对象。</span></div>
  <div><b>fetchQuantityDescription</b><span>从清洁树或批次中取数量、描述和单位。</span></div>
</div>

---
class: talk

## 一个真实切口：瓶颈催办邮件已经能跑成 Agent Skill

<div class="story-wide">
  <div>
    <p class="talk-lead">
工作台里已经有一个具体入口：从批次行触发 AgentPanel，执行 bottleneck_urge skill，最终生成邮件草稿。
    </p>
    <p class="talk-lead">
这页可以作为 Demo 的骨架：不是展示一个大而全的 AI，而是展示 Agent 如何围绕一个履行动作完成一轮执行。
    </p>
  </div>
  <div class="stack compact">
    <div class="line-card"><b>输入</b><span>合同/订单号、瓶颈编码、大调度回复、目标拉动日期。</span></div>
    <div class="line-card"><b>查询</b><span>查合同、批次、清洁树、数量描述、团队路由和收件人。</span></div>
    <div class="line-card"><b>输出</b><span>生成邮件草稿，并保留 Evidence / Trace 供人确认。</span></div>
    <div class="line-card"><b>边界</b><span>它准备动作，不静默发送；人确认后再复制或发邮件。</span></div>
  </div>
</div>

---
class: talk

## Hermes Agent 做的，是把这些工具按业务步骤串起来

<p class="talk-lead">
这时候 Agent 的角色就清楚了：它不是凭空判断，而是按一个任务流程，去调用工具、合并事实、产出可执行的结果。
</p>

<div class="path compact">
  <div class="node"><b>用户任务</b><span>关注某个<br>合同/订单</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>选择 Skill</b><span>匹配履行<br>跟踪流程</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>调用工具</b><span>WeLink / Supply<br>本地工具/API</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>合并事实</b><span>系统状态<br>沟通结论</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>输出动作</b><span>结论、风险<br>进展草稿</span></div>
</div>

<div class="example" style="margin-top:34px;">
  <span class="label">这里的核心变化</span>
  <p>工作台不再只是展示数据，而是开始具备“读取、判断、准备动作”的执行能力。</p>
</div>

---
class: talk

## Hermes Agent 的原理：不是一次回答，而是一轮执行循环

<p class="talk-lead">
Hermes Agent 可以理解成一个“带工具的大模型执行器”。模型负责理解任务和规划步骤，Skill 约束业务流程，WeLink CLI、Supply CLI、本地工具和进展接口负责读取事实和执行动作。
</p>

<div class="path compact">
  <div class="node"><b>理解任务</b><span>我要跟踪哪个<br>合同/订单</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>制定计划</b><span>先查什么<br>再查什么</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>调用工具</b><span>CLI / API<br>本地工具</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>观察结果</b><span>读取返回字段<br>识别缺口</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>继续推进</b><span>补查、总结<br>准备动作</span></div>
</div>

<div class="example" style="margin-top:34px;">
  <span class="label">关键不是“模型一次说对”</span>
  <p>关键是 Agent 能在每一步拿到真实反馈，再决定下一步工具调用或输出。它更像一个可观察、可约束的执行循环。</p>
</div>

---
class: talk

## Hermes Agent 能做什么：围绕业务对象完成四类动作

<p class="talk-lead">
放到订单履行里，Hermes Agent 的能力不应该泛化成“什么都能问”，而是围绕合同/订单这个对象做四类稳定动作。
</p>

<div class="takeaways">
  <div class="takeaway">
    <b>查</b>
    <span>查合同/订单状态、最近消息、邮件和历史进展。</span>
  </div>
  <div class="takeaway">
    <b>对</b>
    <span>把系统状态、沟通事实、历史记录按时间和来源对齐。</span>
  </div>
  <div class="takeaway">
    <b>判</b>
    <span>判断当前结论、风险、冲突口径和缺失信息。</span>
  </div>
</div>

<div class="example" style="margin-top:34px;">
  <span class="label">第四类动作：写</span>
  <p>在用户确认后，把关键结论写入进展。这里不是让 Agent 静默改业务系统，而是让它把“可写入内容”准备好。</p>
</div>

---
class: talk

## 它如何执行：以“跟踪交单进展”为例

<div class="story-wide">
  <div>
    <p class="talk-lead">
用户只说一句“帮我看这个合同/订单最近有没有交单进展”，Agent 背后要做的是一组受控步骤，而不是直接生成一段话。
    </p>
    <p class="talk-lead">
这组步骤的价值，是把散落事实变成可以推进的履行判断。
    </p>
  </div>
  <div class="stack compact">
    <div class="line-card"><b>1. 定位对象</b><span>先确认合同/订单，再取代表批次和当前履行状态。</span></div>
    <div class="line-card"><b>2. 拉沟通</b><span>WeLink CLI 搜最近消息和邮件，提取新事实。</span></div>
    <div class="line-card"><b>3. 查现场</b><span>本地工具查批次、清洁树、关联对象和历史进展。</span></div>
    <div class="line-card"><b>4. 给结果</b><span>输出结论、依据、风险、下一步动作和进展草稿。</span></div>
  </div>
</div>

---
class: talk

## Skill 化：把我的工作方法写给 Agent

<div class="story-wide">
  <div>
    <p class="talk-lead">
工具解决“能不能查”，Skill 解决“应该怎么查、怎么判断、怎么输出”。
    </p>
    <p class="talk-lead">
它更像一份业务 SOP：什么场景触发、需要哪些输入、按什么顺序调用工具、哪些内容必须确认。
    </p>
  </div>
  <div class="light-code"><span class="dim"># follow_delivery_progress.skill</span>
when: 跟踪合同/订单交单进展

inputs:
  - 合同/订单号
  - 时间范围
  - 关注点

steps:
  1. 查合同/订单状态
  2. 查最近消息和邮件
  3. 查历史进展
  4. 对齐事实与冲突
  5. 输出结论和进展草稿

rule:
  <span class="hot">写入进展前必须确认</span></div>
</div>

---
class: talk

## 一个 Skill 要写到“能执行”，不能只写目标

<p class="talk-lead">
如果 Skill 只写“帮我总结一下进展”，Agent 还是会自由发挥。真正能复用的 Skill，要把任务拆成输入、工具、步骤、边界和输出。
</p>

<div class="takeaways">
  <div class="takeaway">
    <b>输入清楚</b>
    <span>合同/订单号、时间范围、关注点、是否允许生成进展草稿。</span>
  </div>
  <div class="takeaway">
    <b>步骤清楚</b>
    <span>先查对象，再查沟通，再查历史进展，最后合并事实。</span>
  </div>
  <div class="takeaway">
    <b>边界清楚</b>
    <span>事实和推测分开；写入前确认；来源不明就标记缺口。</span>
  </div>
</div>

<div class="example" style="margin-top:34px;">
  <span class="label">判断一个 Skill 写得好不好</span>
  <p>不是看它描述得多完整，而是看换一个合同/订单、换一天上下文，它还能不能按同样流程稳定完成任务。</p>
</div>

---
class: talk

## CLI/API 给 Agent 的，不应该只是“能调”，而是稳定契约

<div class="story-wide">
  <div>
    <p class="talk-lead">
工具如果只返回一段人看的文本，Agent 后面很难稳定判断。更好的方式是让 CLI/API 返回结构化结果。
    </p>
    <p class="talk-lead">
也就是说，工具要把“业务事实”变成 Agent 可以可靠使用的字段。
    </p>
    <ul class="bullets" style="margin-top:18px;">
      <li>可定位：合同/订单号、来源、时间、消息或进展 ID。</li>
      <li>可判断：状态字段、沟通结论、附件线索、待确认信息分开。</li>
      <li>可追踪：结论能回到原始来源，不只是给一段摘要。</li>
    </ul>
  </div>
  <div class="light-code" style="font-size:12px; line-height:1.42; padding:16px 18px;"><span class="dim"># 工具返回结果最好接近这种形态</span>
{
  "source": "welink_message",
  "time": "2026-04-28 09:30",
  "contract_order_id": "XXXX",
  "fact": "责任人反馈预计今天确认交单时间",
  "confidence": "from_message",
  "needs_confirm": true
}</div>
</div>

---
class: talk

## Agent 做判断前，要先把事实合并成一张小时间线

<p class="talk-lead">
一个合同/订单的真实状态，往往不是单点字段，而是多个来源在一段时间里的变化。Agent 需要先对齐时间和来源，再给结论。
</p>

<div class="path">
  <div class="node"><b>系统状态</b><span>当前节点<br>交付信息</span></div>
  <div class="arrow">+</div>
  <div class="node"><b>沟通事实</b><span>消息、邮件<br>责任人反馈</span></div>
  <div class="arrow">+</div>
  <div class="node"><b>历史进展</b><span>上次记录<br>已有结论</span></div>
  <div class="arrow">→</div>
  <div class="node"><b>小时间线</b><span>一致项、冲突项<br>缺口项</span></div>
</div>

<div class="comparison">
  <div class="pane">
    <span class="big">不能直接做</span>
    <h3>看到一条消息就下结论</h3>
    <ul class="bullets">
      <li>容易覆盖系统状态</li>
      <li>容易重复写进展</li>
      <li>容易把推测当事实</li>
    </ul>
  </div>
  <div class="pane hot">
    <span class="big">应该先做</span>
    <h3>来源、时间、口径先对齐</h3>
    <ul class="bullets">
      <li>哪些事实相互印证</li>
      <li>哪些口径互相冲突</li>
      <li>还缺哪个关键确认</li>
    </ul>
  </div>
</div>

---
class: talk

## 写入进展要做成闭环：草稿、确认、写入、回查

<p class="talk-lead">
越靠近业务记录，越不能只靠“模型觉得可以”。进展写入需要一条明确闭环，保证可控和可追踪。
</p>
<p class="talk-lead" style="margin-top:14px;">
这也是为什么我倾向于后续把进展接口封装成 Supply CLI，而不是长期让 Agent 直接拼原始 API。
</p>

<div class="example" style="margin-top:26px;">
  <span class="label">这里的工程化重点</span>
  <p>Agent 可以提高效率，但业务变更动作要有确认点、有来源、有日志。否则越自动，风险越大。</p>
</div>

---
class: talk

## Demo：重点不是答案，而是执行轨迹

<p class="talk-lead">
这个 Demo 不需要假装有很复杂的报表。要展示的是 Agent 如何一步步调用工具、拿到证据、生成制品，并把异常暴露出来。
</p>

<div class="story-wide">
  <div class="example">
    <span class="label">建议演示方式</span>
    <p>从一个真实批次行触发 AgentPanel，输入瓶颈编码和调度回复，让大家看见 Artifact、Evidence、Trace 三层。</p>
  </div>
  <div class="stack">
    <div class="line-card"><b>看输入</b><span>合同/订单号自动带入，瓶颈编码和目标日期由人确认。</span></div>
    <div class="line-card"><b>看工具</b><span>Trace 展示查合同、查批次、查清洁树、查收件人的过程。</span></div>
    <div class="line-card"><b>看制品</b><span>最终产出邮件草稿或进展草稿，人确认后再执行。</span></div>
  </div>
</div>

---
class: talk

## 每日履行简报：不是消息摘要，而是履行变化

<div class="story">
  <div>
    <p class="talk-lead">
简报真正有价值的地方，不是把聊天记录压缩成几段话，而是告诉我：今天哪些合同/订单的履行状态发生了变化。
    </p>
    <p class="talk-lead">
它应该围绕“变化、风险、动作”组织，而不是围绕消息来源组织。
    </p>
  </div>
  <div class="stack">
    <div class="line-card"><b>今天变了什么</b><span>系统状态、交付节点、沟通结论有没有新的变化。</span></div>
    <div class="line-card"><b>哪里需要关注</b><span>哪些对象出现阻塞、口径冲突或需要补问。</span></div>
    <div class="line-card"><b>下一步做什么</b><span>该催办谁、确认什么、是否需要写进展。</span></div>
  </div>
</div>

---
class: talk

## 重点监控：让 Agent 记得持续看

<p class="talk-lead">
有些合同/订单不是看一次就结束，而是需要持续关注。Agent 可以维护一个关注列表，周期性检查变化。
</p>

<div class="story-wide">
  <div class="example">
    <span class="label">适合放进关注列表的对象</span>
    <p>重点客户相关、交单节点临近、近期沟通密集、或者人工标记需要盯办的合同/订单。</p>
  </div>
  <div class="stack">
    <div class="line-card"><b>状态变化</b><span>系统字段或履行节点有没有更新。</span></div>
    <div class="line-card"><b>沟通变化</b><span>是否出现新的消息、邮件、承诺或原因。</span></div>
    <div class="line-card"><b>进展缺口</b><span>是否需要补充记录，或者已有记录过期。</span></div>
  </div>
</div>

---
class: talk

## 异常解释：先列事实，再给判断

<div class="story">
  <div>
    <p class="talk-lead">
履行异常经常不是“没有信息”，而是信息分散在不同来源里。系统字段、群消息、邮件口径、历史进展可能并不一致。
    </p>
    <p class="talk-lead">
Agent 的价值不是直接拍脑袋给结论，而是先把事实摆出来，再指出一致项、冲突项和缺口项。
    </p>
  </div>
  <div class="comparison tight" style="grid-template-columns:1fr;">
    <div class="pane">
      <h3>事实层</h3>
      <p class="talk-note">系统字段、WeLink 消息、邮件、历史进展分别说了什么。</p>
    </div>
    <div class="pane hot">
      <h3>判断层</h3>
      <p class="talk-note">哪些内容互相印证，哪些口径冲突，下一步需要谁确认。</p>
    </div>
  </div>
</div>

---
class: talk

## 我觉得真正有价值的，是这三个变化

<div class="takeaways">
  <div class="takeaway">
    <b>少切系统</b>
    <span>不用每次都在系统、消息、邮件、进展之间来回跳。</span>
  </div>
  <div class="takeaway">
    <b>少重复整理</b>
    <span>沟通里的关键结论可以直接变成结构化摘要和进展草稿。</span>
  </div>
  <div class="takeaway">
    <b>少丢业务记忆</b>
    <span>重要信息不只停留在聊天里，而是沉淀回履行进展。</span>
  </div>
</div>

<p class="talk-lead" style="margin-top:46px;">
这不是“让 AI 替人做决定”，而是把大量找事实、对上下文、整理进展的工作交给 Agent 先做一遍。
</p>

---
class: talk

## 后续演进：先跑通闭环，再扩大范围

<p class="talk-lead">
这件事不需要一开始就做成大平台。更实际的路径，是先围绕一个合同/订单跑通，再把能力扩到更多场景。
</p>

<div class="mini-timeline">
  <div>
    <b>现在</b>
    <span>supply-chrome 工作台、本地工具、AgentPanel、WeLink CLI、Supply CLI、进展 API 已经能支撑基本闭环。</span>
  </div>
  <div>
    <b>近期</b>
    <span>把履行跟踪、每日简报、重点监控沉淀成稳定 Skill。</span>
  </div>
  <div>
    <b>中期</b>
    <span>把进展查询和写入封装进 Supply CLI，统一工具边界。</span>
  </div>
  <div>
    <b>未来</b>
    <span>通过正式 API 或数据库能力，把工作台升级为团队级执行中枢。</span>
  </div>
</div>

---
class: talk

## 最后，用一句话收束

<p class="speech" style="font-size:30px; max-width:880px;">
订单履行工作台的下一步，不只是把数据展示得更好，而是让 Agent 带着工具链进入业务现场，帮助我们推进执行。
</p>

<div class="takeaways">
  <div class="takeaway">
    <b>可读取</b>
    <span>消息、邮件、合同/订单、进展能进入 Agent 上下文。</span>
  </div>
  <div class="takeaway">
    <b>可执行</b>
    <span>Agent 能按 Skill 调工具，生成结论和动作草稿。</span>
  </div>
  <div class="takeaway">
    <b>可沉淀</b>
    <span>关键进展回到业务系统，而不是散落在沟通里。</span>
  </div>
</div>