feat: 支持多语言提示词本地化和界面优化
- 添加 prompt_locale 参数支持简体中文、繁体中文和英文提示词本地化 - 移除内置 agents 配置以简化系统架构 - 更新 ContextBuilder 使用动态提示词模板而非硬编码内容 - 在 AgentLoop、Web 接口和 AgentService 中传递 locale 参数 - 添加输出语言指令确保用户界面内容按指定语言生成 - 扩展前端 LanguageSwitcher 组件支持三种语言选项 - 优化 Header 和侧边栏组件的响应式布局和文本截断处理 - 更新测试用例验证不同语言环境下的提示词正确性
This commit is contained in:
@ -3,7 +3,7 @@
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Beaver Skill Replay Eval · 技术方案介绍</title>
|
||||
<title>Beaver Agent Sandbox · 客户方案介绍</title>
|
||||
<link rel="stylesheet" href="assets/fonts.css">
|
||||
<link rel="stylesheet" href="assets/base.css">
|
||||
<link rel="stylesheet" href="assets/animations/animations.css">
|
||||
@ -13,383 +13,271 @@
|
||||
<div class="deck">
|
||||
|
||||
<section class="slide" data-title="Cover">
|
||||
<p class="kicker">Beaver Project / Skill Learning</p>
|
||||
<h1 class="h1">Skill Replay Eval<br><span class="gradient-text">从文本评分到行为证据</span></h1>
|
||||
<p class="lede">让技能草稿评估真正覆盖任务执行、工具调用、副作用和草稿保真，而不是只看生成文本是否“像一个好技能”。</p>
|
||||
<p class="kicker">Beaver Agent Sandbox</p>
|
||||
<h1 class="h1">企业级智能体沙盒<br><span class="gradient-text">从 AI 对话到可交付任务</span></h1>
|
||||
<p class="lede">为企业提供可私有部署、可追踪、可验收、可复用的 AI Agent 工作台，让智能体真正进入业务流程，而不只是停留在聊天窗口。</p>
|
||||
<div class="speaker">
|
||||
<div class="av"></div>
|
||||
<div><b>Beaver 技能学习评估方案</b><span>技术分享 · 架构设计 · UI 与测试路线</span></div>
|
||||
<div><b>Beaver 客户方案介绍</b><span>产品展示 · 商业价值 · 落地路径</span></div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>skill-replay-eval-design.md</span><span class="slide-number" data-current="1" data-total="13"></span></div>
|
||||
<div class="deck-footer"><span>Agent Sandbox for enterprise teams</span><span class="slide-number" data-current="1" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这一页先建立主题。我们不是在做一个更复杂的“打分器”，而是在把技能评估从静态文本判断，推进到真实任务行为判断。核心信息有三层：第一，技能草稿要在历史任务中复跑；第二，所有工具都要被纳入覆盖，只是安全工具真实执行，危险工具用替身判断；第三，修改已有技能时必须保留原有关键内容，不能因为重新生成而把重要说明丢掉。
|
||||
开场不要先讲技术，而是讲客户能听懂的定位：Beaver 是一个企业级智能体沙盒。它的价值不是“又一个聊天机器人”，而是把 AI 从问答推进到任务执行、过程追踪、结果验收和经验复用。客户最关心的是能不能落地到真实工作、能不能管控风险、能不能把成功经验变成组织资产。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Project Context">
|
||||
<p class="kicker">system context</p>
|
||||
<h2 class="h2">Beaver 是多实例 AI 工作台，Skill Replay Eval 位于单实例技能学习链路。</h2>
|
||||
<div class="flow mt-l">
|
||||
<div class="flow-step"><span class="n">01</span><h4>auth-portal</h4><p>用户注册、登录和模型配置引导入口。</p></div>
|
||||
<div class="flow-step"><span class="n">02</span><h4>authz-service</h4><p>账号、后端身份和内部授权编排。</p></div>
|
||||
<div class="flow-step"><span class="n">03</span><h4>deploy-control</h4><p>创建、配置和管理独立 app-instance 容器。</p></div>
|
||||
<div class="flow-step"><span class="n">04</span><h4>router-proxy</h4><p>按实例域名把外部流量转发到对应容器。</p></div>
|
||||
<div class="flow-step card-accent"><span class="n">05</span><h4>app-instance</h4><p>单用户工作台，包含前端、后端、workspace 和 skills。</p></div>
|
||||
</div>
|
||||
<section class="slide" data-title="Customer Problem">
|
||||
<p class="kicker">why now</p>
|
||||
<h2 class="h2">大多数企业 AI 试点卡在“能聊”，但离“能交付”还差一层操作系统。</h2>
|
||||
<div class="grid g3 mt-l">
|
||||
<div class="card card-accent"><h4>技能页</h4><p class="dim">处理 published skills、candidates、draft review。</p></div>
|
||||
<div class="card card-accent"><h4>学习管线</h4><p class="dim">从历史任务发现候选，合成草稿，再进行安全和评估门禁。</p></div>
|
||||
<div class="card card-accent"><h4>本方案</h4><p class="dim">增强草稿评估，给发布前审查提供可追溯证据。</p></div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>project boundary: app-instance/backend + app-instance/frontend</span><span class="slide-number" data-current="2" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
先把项目放在整体架构里。Beaver 的外层是多实例部署系统，用户最终进入自己的 app-instance。技能学习、草稿评审、发布门禁都发生在 app-instance 内。也就是说 Replay Eval 不是登录系统或部署控制面功能，它服务的是单用户实例里的技能生命周期：发现候选，生成草稿，评估草稿，人工审核，然后发布为新的技能版本。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Current Gap">
|
||||
<p class="kicker">current_state.py</p>
|
||||
<h2 class="h2">旧评估的问题：它在评“草稿文本”，不是评“任务结果”。</h2>
|
||||
<div class="compare mt-l">
|
||||
<div class="side">
|
||||
<span class="tag bad">heuristic-only</span>
|
||||
<h3 class="mt-m">现状</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>只从 candidate.source_run_ids 构造轻量报告。</li>
|
||||
<li>历史 run 使用 validation_result.score 或 success fallback。</li>
|
||||
<li>候选得分主要估算自 draft text。</li>
|
||||
<li>不复跑任务，不执行工具，不比较旧技能和新草稿行为。</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="side candidate">
|
||||
<span class="tag good">behavior evidence</span>
|
||||
<h3 class="mt-m">目标</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>用历史任务作为 eval cases，运行 baseline 与 candidate 两个 arm。</li>
|
||||
<li>安全工具真实执行，危险或不可用工具进入 surrogate 判断。</li>
|
||||
<li>报告分开披露执行覆盖、替身覆盖、阻塞覆盖和置信度。</li>
|
||||
<li>修订和合并草稿必须证明没有无理由丢失原技能内容。</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>risk: high-looking score can still hide tool regressions</span><span class="slide-number" data-current="3" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这一页强调为什么要改。旧逻辑并非没有价值，它能快速给一个草稿粗略打分。但它无法回答发布前最关键的问题：这个技能真的会让任务做得更好吗？会不会漏掉工具调用？会不会多做一次危险操作？会不会把原技能里的安全说明删了？所以新方案的目标不是替换所有历史字段，而是在兼容旧 UI 的基础上新增 replay 证据。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Eval Model">
|
||||
<p class="kicker">evaluation_model</p>
|
||||
<h2 class="h2">核心模型：历史 case 选择 + 双臂 replay。</h2>
|
||||
<div class="split mt-l">
|
||||
<div class="card">
|
||||
<h3>Case selection</h3>
|
||||
<div class="matrix mt-m">
|
||||
<div class="head">候选类型</div><div class="head">选择来源</div><div class="head">优先级</div><div class="head">规模</div>
|
||||
<div class="rowhead">new_skill</div><div>source runs + 相似主题 accepted runs</div><div>相似任务主题</div><div>最多 10 个</div>
|
||||
<div class="rowhead">revise_skill</div><div>激活目标 skill/version 的 accepted runs</div><div>近期优先，再按任务分散</div><div>最多 10 个</div>
|
||||
<div class="rowhead">merge_skills</div><div>相关 skills 共同激活的 accepted runs</div><div>共同出现证据</div><div>最多 10 个</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Two arms</h3>
|
||||
<div class="pipeline mt-m">
|
||||
<div class="phase"><span class="tag">same task</span><h3>输入一致</h3><p class="dim">同一任务文本、同一历史上下文、同一模型设置、同一最大工具迭代数。</p></div>
|
||||
<div class="phase"><span class="tag warn">baseline</span><h3>旧行为</h3><p class="dim">new_skill 无技能；revise_skill 用旧技能；merge_skills 用旧相关技能。</p></div>
|
||||
<div class="phase"><span class="tag good">candidate</span><h3>新草稿</h3><p class="dim">将 draft skill 作为 pinned draft guidance 注入，并记录行为差异。</p></div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>same inputs, different skill guidance, comparable outputs</span><span class="slide-number" data-current="4" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
新评估的基本单元是 historical case。每个 case 都跑两个 arm：baseline 代表当前已有能力，candidate 代表注入草稿后的能力。为了让对比有意义，两个 arm 除了技能引导不同以外，其他条件都尽量一致。这样我们评估的不是模型随机性，也不是不同上下文造成的差异，而是草稿技能本身对任务行为的影响。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Tool Modes">
|
||||
<p class="kicker">tool_policy</p>
|
||||
<h2 class="h2">所有工具都被覆盖，只是进入不同执行模式。</h2>
|
||||
<div class="metric-grid mt-l">
|
||||
<div class="metric"><span>mode</span><b>executed</b><p class="dim">能安全隔离的工具，在 replay 环境中真实执行。</p></div>
|
||||
<div class="metric"><span>mode</span><b>surrogate</b><p class="dim">不能安全执行，但记录 intended call，由 LLM 替身判断效果。</p></div>
|
||||
<div class="metric"><span>mode</span><b>blocked</b><p class="dim">既不能执行，也无法可靠判断，明确降低置信度。</p></div>
|
||||
<div class="metric"><span>report</span><b>coverage</b><p class="dim">执行、替身、阻塞覆盖率分开披露。</p></div>
|
||||
</div>
|
||||
<div class="matrix mt-l">
|
||||
<div class="head">工具类型</div><div class="head">默认模式</div><div class="head">原因</div><div class="head">例子</div>
|
||||
<div class="rowhead">workspace read/write</div><div><span class="tag good">executed</span></div><div>可在临时 workspace clone 中执行</div><div>读写代码、生成文件、测试 artifact</div>
|
||||
<div class="rowhead">web/search read</div><div><span class="tag good">executed</span></div><div>只读且可缓存输出</div><div>搜索、打开网页、读取公开文档</div>
|
||||
<div class="rowhead">external write</div><div><span class="tag warn">surrogate</span></div><div>默认不能写生产第三方系统</div><div>邮件、日历、消息发送</div>
|
||||
<div class="rowhead">destructive action</div><div><span class="tag bad">surrogate / blocked</span></div><div>删除、支付、权限变更不可自动执行</div><div>不可逆外部写入</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>principle: include third-party tools without production side effects</span><span class="slide-number" data-current="5" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
一个重要原则是“不要忽略工具”。如果只评估安全工具，那第三方连接器、发送类工具和破坏性工具就会从报告里消失，风险反而被掩盖。这里的做法是：能隔离的就真实执行；不能隔离的就记录意图，并用替身评估它是否正确、完整、必要、有无风险；如果替身也无法判断，就明确标记 blocked，让报告和发布门禁知道置信度不足。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Replay Environment">
|
||||
<p class="kicker">replay_environment</p>
|
||||
<h2 class="h2">隔离 replay 环境：让任务复跑有证据，但不污染真实世界。</h2>
|
||||
<div class="split mt-l">
|
||||
<div>
|
||||
<p class="lede">每个 case、每个 arm 都创建独立状态。runner 负责执行、拦截、记录，评估器在 runner 外部读取 artifacts 和 side effects。</p>
|
||||
<div class="grid g2 mt-l">
|
||||
<div class="panel"><span class="tag">session</span><h4 class="mt-s">Temporary session id</h4><p class="dim">避免污染真实会话状态。</p></div>
|
||||
<div class="panel"><span class="tag">workspace</span><h4 class="mt-s">Temporary workspace root</h4><p class="dim">文件读写落在临时 clone。</p></div>
|
||||
<div class="panel"><span class="tag">trace</span><h4 class="mt-s">Tool call trace</h4><p class="dim">记录调用、参数、模式和理由。</p></div>
|
||||
<div class="panel"><span class="tag">journal</span><h4 class="mt-s">Side-effect journal</h4><p class="dim">外部写入不落生产，只留证据。</p></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="terminal">
|
||||
<div class="bar"><span class="dot"></span><span class="dot"></span><span class="dot"></span><span>replay_case.json</span></div>
|
||||
<pre>{
|
||||
<span class="str">"case_id"</span>: <span class="str">"run-accepted-042"</span>,
|
||||
<span class="str">"arm"</span>: <span class="str">"candidate"</span>,
|
||||
<span class="str">"workspace_root"</span>: <span class="str">"/tmp/beaver-replay/..."</span>,
|
||||
<span class="str">"tool_calls"</span>: [
|
||||
{ <span class="str">"tool"</span>: <span class="str">"filesystem.write"</span>,
|
||||
<span class="str">"mode"</span>: <span class="str">"executed"</span> },
|
||||
{ <span class="str">"tool"</span>: <span class="str">"outlook.send_mail"</span>,
|
||||
<span class="str">"mode"</span>: <span class="str">"surrogate"</span> }
|
||||
],
|
||||
<span class="str">"artifacts"</span>: [<span class="str">"draft.md"</span>],
|
||||
<span class="str">"side_effects"</span>: [<span class="str">"intended_email"</span>]
|
||||
}</pre>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>pattern: OfficeBench-style isolated testbed, adapted to Beaver skills</span><span class="slide-number" data-current="6" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这里可以用一句话概括：runner 是沙盒执行器，evaluator 是证据裁判。我们不让 replay 直接写用户 workspace、用户文件、长期 memory、第三方账号或外部系统。每个 arm 有自己的临时 workspace、工具 trace、输出 artifacts 和 side-effect journal。这个形状借鉴了 OfficeBench MCP 的思路，但不绑定固定 benchmark 函数，而是服务 Beaver 的历史任务。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Surrogate Evaluation">
|
||||
<p class="kicker">surrogate_evaluator</p>
|
||||
<h2 class="h2">替身评估不是跳过工具，而是评估 intended effect。</h2>
|
||||
<div class="split mt-l">
|
||||
<div class="card">
|
||||
<h3>输入 payload</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>工具名称和 schema。</li>
|
||||
<li>候选 arm 计划调用的 arguments。</li>
|
||||
<li>工具被分类为 surrogate 的原因。</li>
|
||||
<li>历史 accepted evidence 和任务预期副作用。</li>
|
||||
<li>assistant 在调用前后的 rationale。</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="card card-accent">
|
||||
<h3>判断维度</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>调用是否满足任务目标。</li>
|
||||
<li>参数是否完整、正确、可执行。</li>
|
||||
<li>是否遗漏、重复或不必要。</li>
|
||||
<li>是否有越权、危险或不可逆风险。</li>
|
||||
<li>candidate 相比 baseline 是否真实改善。</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="terminal mt-l">
|
||||
<div class="bar"><span class="dot"></span><span class="dot"></span><span class="dot"></span><span>surrogate_score.py</span></div>
|
||||
<pre>candidate_score = quality(intended_effect, arguments, evidence)
|
||||
risk_penalty = risk(missing_args, duplicated_calls, unsafe_scope)
|
||||
confidence = lower_than_real_execution
|
||||
|
||||
case_score = candidate_score - risk_penalty</pre>
|
||||
</div>
|
||||
<div class="deck-footer"><span>surrogate contributes to score, but lowers confidence</span><span class="slide-number" data-current="7" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
替身评估要避免两个误解。第一，它不是把危险工具当作成功，而是把“模型打算怎么调用工具”拿出来审。第二，它的置信度天然低于真实执行。比如发送邮件不能真的发，但我们可以判断收件人、主题、正文、附件、发送时机是否符合任务，也能判断是否重复发送、是否包含敏感信息、是否越权。这些判断会进入分数，但会降低 confidence。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Scoring And Gates">
|
||||
<p class="kicker">report_and_gates</p>
|
||||
<h2 class="h2">报告兼容旧 UI，同时新增 replay 证据和发布门禁信号。</h2>
|
||||
<div class="metric-grid mt-l">
|
||||
<div class="metric"><span>legacy</span><b>passed</b><p class="dim">保留 passed、score_delta、cases、status 等旧字段。</p></div>
|
||||
<div class="metric"><span>coverage</span><b>3 modes</b><p class="dim">execution、surrogate、blocked coverage。</p></div>
|
||||
<div class="metric"><span>quality</span><b>delta</b><p class="dim">baseline mean、candidate mean、improved/regression count。</p></div>
|
||||
<div class="metric"><span>trust</span><b>confidence</b><p class="dim">低置信度不能自动等同可发布。</p></div>
|
||||
</div>
|
||||
<div class="split mt-l">
|
||||
<div class="terminal">
|
||||
<div class="bar"><span class="dot"></span><span class="dot"></span><span class="dot"></span><span>SkillDraftEvalReport</span></div>
|
||||
<pre>{
|
||||
<span class="str">"eval_version"</span>: <span class="str">"replay-v1"</span>,
|
||||
<span class="str">"mode"</span>: <span class="str">"replay"</span>,
|
||||
<span class="str">"execution_coverage"</span>: <span class="num">0.58</span>,
|
||||
<span class="str">"surrogate_coverage"</span>: <span class="num">0.33</span>,
|
||||
<span class="str">"blocked_coverage"</span>: <span class="num">0.09</span>,
|
||||
<span class="str">"confidence"</span>: <span class="str">"medium"</span>,
|
||||
<span class="str">"case_reports"</span>: [...],
|
||||
<span class="str">"tool_mode_summary"</span>: {...}
|
||||
}</pre>
|
||||
</div>
|
||||
<div class="card card-accent">
|
||||
<h3>Publish gate logic</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>高分但低置信度，进入更强人工 review。</li>
|
||||
<li>重要工具全部 blocked，不允许自动 pass。</li>
|
||||
<li>部分 case 失败，status = partial，降低 confidence。</li>
|
||||
<li>replay 基础设施失败，status = replay_error。</li>
|
||||
<li>provider 不可用时保留 skipped-provider 行为，但标明没有 replay evidence。</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>score answers quality, confidence answers how much we can trust it</span><span class="slide-number" data-current="8" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
报告设计的关键是兼容而不是推倒重来。旧字段继续保留，这样 UI 和存储不会被迫一次性迁移。新字段回答三个问题：我们执行了多少工具？多少工具只能替身判断？多少工具被阻塞？最后 confidence 会参与发布门禁。也就是说，一个草稿即使分数看起来不错，如果证据主要来自替身，或者关键工具全 blocked，也不应该自动放行。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Draft Preservation">
|
||||
<p class="kicker">preservation_contract</p>
|
||||
<h2 class="h2">修订草稿必须保留原技能内容，除非明确说明改变理由。</h2>
|
||||
<div class="split mt-l">
|
||||
<div class="card">
|
||||
<h3>为什么需要</h3>
|
||||
<p class="lede mt-m">现有 synthesizer 对 revision 和 merge 只拿到候选理由、相关技能名、工具名、任务摘要和 session excerpts，没有完整 base skill body。</p>
|
||||
<div class="panel mt-m"><span class="tag bad">failure mode</span><p class="dim mt-s">重新生成看起来更整洁，但可能丢掉原技能里的安全边界、工具约束、工作流顺序和异常处理。</p></div>
|
||||
</div>
|
||||
<div class="card card-accent">
|
||||
<h3>新合同</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>向 synthesis prompt 传入 base skill name、version、完整 frontmatter 和完整 content。</li>
|
||||
<li>要求模型默认保留现有指令，只有在明确理由下才改变。</li>
|
||||
<li>输出 preserved_sections、changed_sections、dropped_sections、change_reason。</li>
|
||||
<li>preservation checker 比较 base 和 draft，未解释的关键丢失会标记风险。</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>revision is an edit contract, not a fresh rewrite</span><span class="slide-number" data-current="9" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这一页是第二条主线：草稿保真。Replay 评估解决“行为是否更好”，preservation 解决“原来重要的东西有没有丢”。对于修订和合并技能，模型必须看到完整 base skill，不能只看摘要。生成结果也不只是一个新 body，还要解释保留了什么、改了什么、删了什么以及为什么删。这样评审者能判断这是合理修订，还是无意丢失。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Implementation">
|
||||
<p class="kicker">implementation_plan</p>
|
||||
<h2 class="h2">实现路径：扩展现有技能学习管线，新增小模块而不是重写系统。</h2>
|
||||
<div class="pipeline mt-l">
|
||||
<div class="phase card-accent">
|
||||
<span class="tag">backend model</span>
|
||||
<h3>数据层兼容</h3>
|
||||
<ul class="clean">
|
||||
<li>扩展 SkillDraftEvalReport。</li>
|
||||
<li>新增 replay 字段默认值。</li>
|
||||
<li>保留旧 payload 读取能力。</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="phase card-accent">
|
||||
<span class="tag">learning helpers</span>
|
||||
<h3>评估能力拆分</h3>
|
||||
<ul class="clean">
|
||||
<li>case_selection.py</li>
|
||||
<li>preservation.py</li>
|
||||
<li>replay.py</li>
|
||||
<li>surrogate.py</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="phase card-accent">
|
||||
<span class="tag">pipeline + ui</span>
|
||||
<h3>接入和展示</h3>
|
||||
<ul class="clean">
|
||||
<li>eval.py 编排 replay。</li>
|
||||
<li>pipeline.py 更新发布门禁。</li>
|
||||
<li>loop.py 支持 replay executor override。</li>
|
||||
<li>Skills UI 展示 coverage、case 和 preservation。</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="terminal mt-l">
|
||||
<div class="bar"><span class="dot"></span><span class="dot"></span><span class="dot"></span><span>target files</span></div>
|
||||
<pre>app-instance/backend/beaver/skills/learning/
|
||||
case_selection.py
|
||||
preservation.py
|
||||
replay.py
|
||||
surrogate.py
|
||||
eval.py
|
||||
synthesizer.py
|
||||
pipeline.py
|
||||
|
||||
app-instance/frontend/app/(app)/skills/page.tsx
|
||||
app-instance/frontend/types/index.ts</pre>
|
||||
</div>
|
||||
<div class="deck-footer"><span>architecture: focused helpers under existing SkillLearningPipelineService.evaluate_draft()</span><span class="slide-number" data-current="10" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
实现策略很保守：扩展现有技能学习管线，而不是引入一套平行系统。数据模型先兼容扩展，然后把 case selection、preservation、replay、surrogate 拆成小模块。eval.py 负责 orchestrate，pipeline.py 负责发布门禁，loop.py 给 replay executor 一个注入点。前端只是在草稿评审页增加证据展示，并保留已有摘要入口。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="UI">
|
||||
<p class="kicker">skills_review_ui</p>
|
||||
<h2 class="h2">评审页先给结论，再让审核者展开证据。</h2>
|
||||
<div class="split mt-l">
|
||||
<div class="card card-accent">
|
||||
<h3>Concise summary</h3>
|
||||
<div class="metric-grid mt-m" style="grid-template-columns: repeat(2, 1fr);">
|
||||
<div class="metric"><span>pass</span><b>failed</b><p class="dim">发布门禁结论。</p></div>
|
||||
<div class="metric"><span>delta</span><b>+0.18</b><p class="dim">candidate - baseline。</p></div>
|
||||
<div class="metric"><span>exec</span><b>58%</b><p class="dim">真实执行覆盖。</p></div>
|
||||
<div class="metric"><span>conf</span><b>medium</b><p class="dim">证据可信度。</p></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="card">
|
||||
<h3>Detailed evidence</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>Replay cases：每个历史任务的 baseline/candidate 分数。</li>
|
||||
<li>Tool calls by mode：executed、surrogate、blocked 分类和理由。</li>
|
||||
<li>Artifacts and side effects：产物和副作用 journal。</li>
|
||||
<li>Preservation report：修订草稿的保留、变更、删除风险。</li>
|
||||
<li>Raw eval payload：保留完整 JSON 供深度排查。</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="card card-accent"><h4>结果不可验收</h4><p class="dim">模型回答看起来合理，但缺少任务状态、修改闭环、产物管理和用户确认。</p><span class="tag bad mt-s">chat-only</span></div>
|
||||
<div class="card card-accent"><h4>过程不可审计</h4><p class="dim">工具用了什么、文件改了什么、依据来自哪里，常常没有清晰证据链。</p><span class="tag warn mt-s">black box</span></div>
|
||||
<div class="card card-accent"><h4>经验不可复用</h4><p class="dim">一次成功交付没有沉淀成团队方法，下一次仍然依赖人工提示和临场判断。</p><span class="tag mt-s">one-off</span></div>
|
||||
</div>
|
||||
<div class="panel mt-l">
|
||||
<span class="tag good">UX principle</span>
|
||||
<p class="lede mt-s">用户不需要预先配置每个工具的策略。系统在报告里解释覆盖、阻塞和不确定性，让审核者知道该相信多少。</p>
|
||||
<span class="tag good">Beaver 的切入点</span>
|
||||
<p class="lede mt-s">把智能体运行所需的任务、工具、文件、记忆、技能、验收和多实例部署统一到一个可控沙盒里。</p>
|
||||
</div>
|
||||
<div class="deck-footer"><span>page: app-instance/frontend/app/(app)/skills/page.tsx</span><span class="slide-number" data-current="11" data-total="13"></span></div>
|
||||
<div class="deck-footer"><span>customer pain: execution, control, reuse</span><span class="slide-number" data-current="2" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
UI 的目标不是把评审页变复杂，而是让复杂证据有层次。最上面仍然是 pass/fail、baseline mean、candidate mean、delta、coverage、confidence。审核者需要细看时，才展开 replay cases、工具模式、阻塞理由、artifacts、副作用和 preservation report。普通使用者不需要理解每个工具策略，系统在评估后解释不确定性。
|
||||
这一页用客户语言讲痛点。企业不是没有模型，也不是不能接一个聊天入口。真正的问题是：回答之后谁来确认？执行过程能不能追溯？文件和工具调用有没有边界？成功经验能不能变成下次自动调用的方法？Beaver 的价值就是补上这层“智能体操作系统”。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Testing And Next Steps">
|
||||
<p class="kicker">testing_strategy</p>
|
||||
<h2 class="h2">交付标准：覆盖决策逻辑与真实工具形态。</h2>
|
||||
<section class="slide" data-title="Product Positioning">
|
||||
<p class="kicker">positioning</p>
|
||||
<h2 class="h2">Beaver 的定位：企业 AI Agent 的执行与治理平台。</h2>
|
||||
<div class="flow mt-l">
|
||||
<div class="flow-step"><span class="n">01</span><h4>识别</h4><p>判断用户是在普通对话，还是在交办需要持续完成的任务。</p></div>
|
||||
<div class="flow-step"><span class="n">02</span><h4>执行</h4><p>按任务选择模型、技能和工具，处理文件、搜索、终端或外部连接器。</p></div>
|
||||
<div class="flow-step"><span class="n">03</span><h4>追踪</h4><p>记录过程、工具调用、子任务、产物、通知和执行证据。</p></div>
|
||||
<div class="flow-step"><span class="n">04</span><h4>验收</h4><p>支持满意、修改、放弃，让用户反馈成为质量闭环。</p></div>
|
||||
<div class="flow-step card-accent"><span class="n">05</span><h4>沉淀</h4><p>把被认可的工作方法转为技能和长期记忆，形成组织资产。</p></div>
|
||||
</div>
|
||||
<div class="metric-grid mt-l">
|
||||
<div class="metric"><span>deployment</span><b>多实例</b><p class="dim">每个用户/团队可拥有独立 app-instance。</p></div>
|
||||
<div class="metric"><span>workspace</span><b>沙盒</b><p class="dim">文件、配置和运行数据在实例边界内管理。</p></div>
|
||||
<div class="metric"><span>control</span><b>验收</b><p class="dim">AI 产出以用户是否认可作为闭环信号。</p></div>
|
||||
<div class="metric"><span>growth</span><b>技能库</b><p class="dim">成功任务经验可持续复用。</p></div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>not a chatbot, an agent execution layer</span><span class="slide-number" data-current="3" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这里要把产品定位说清楚：Beaver 不是单纯的聊天前端，也不是一个模型代理。它是一层智能体执行与治理平台。用户一句话进来，系统能判断是否进入任务模式，随后执行、追踪、验收，并把成功经验沉淀为长期能力。这就是客户购买的核心价值。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Product Modules">
|
||||
<p class="kicker">product modules</p>
|
||||
<h2 class="h2">一套完整工作台：从日常协作到工具治理都在同一界面。</h2>
|
||||
<div class="roadmap mt-l">
|
||||
<div class="item"><span>01</span><b>模型兼容</b><p>旧 payload 可读，新 replay 字段可写，UI 不被旧数据破坏。</p></div>
|
||||
<div class="item"><span>02</span><b>核心逻辑</b><p>case selection、arm construction、tool mode aggregation、surrogate payload。</p></div>
|
||||
<div class="item"><span>03</span><b>保真检查</b><p>base section 保留、删除风险、publish gate 对 preservation risk 的处理。</p></div>
|
||||
<div class="item"><span>04</span><b>混合工具</b><p>安全文件写真实执行，外部写入被拦截为 surrogate，生成可审计报告。</p></div>
|
||||
<div class="item"><span>01</span><b>对话工作台</b><p>会话、附件、Agent 运行过程、当前任务进度和验收操作。</p></div>
|
||||
<div class="item"><span>02</span><b>任务中心</b><p>普通任务、定时任务、任务详情、时间线和结果验收。</p></div>
|
||||
<div class="item"><span>03</span><b>文件空间</b><p>上传、目录管理、Markdown/文本/图片预览、下载和删除。</p></div>
|
||||
<div class="item"><span>04</span><b>技能与市场</b><p>企业技能库、草稿评审、发布门禁和技能安装。</p></div>
|
||||
</div>
|
||||
<div class="roadmap mt-m">
|
||||
<div class="item"><span>05</span><b>工具管理</b><p>MCP 工具配置、工具详情、测试、编辑和删除。</p></div>
|
||||
<div class="item"><span>06</span><b>通知与定时</b><p>周期任务、主动提醒、运行记录和后续修改。</p></div>
|
||||
<div class="item"><span>07</span><b>连接器</b><p>Outlook 等外部系统接入，承接邮件、日历和业务入口。</p></div>
|
||||
<div class="item"><span>08</span><b>配置中心</b><p>模型供应商、Agent profile、通道、系统状态和运行参数。</p></div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>customer-facing workspace, admin-facing control</span><span class="slide-number" data-current="4" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这一页适合给客户展示产品范围。Beaver 不是单点工具，而是一套工作台。对普通用户来说，有对话、任务、文件和通知。对管理员或实施团队来说，有技能、工具、连接器、模型配置和系统状态。这样客户能看到它不是 demo，而是可以承载真实使用流程的产品。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Business Scenarios">
|
||||
<p class="kicker">use cases</p>
|
||||
<h2 class="h2">典型客户场景：高频、跨工具、需要留痕的知识工作。</h2>
|
||||
<div class="grid g3 mt-l">
|
||||
<div class="card card-accent"><h4>项目交付助手</h4><p class="dim">梳理需求、拆任务、生成方案、跟踪修改意见，把交付过程沉淀为可复用模板。</p></div>
|
||||
<div class="card card-accent"><h4>运营与周报自动化</h4><p class="dim">定时触发数据整理、状态汇总、风险提醒和通知推送，减少重复人工跟进。</p></div>
|
||||
<div class="card card-accent"><h4>企业知识与文件处理</h4><p class="dim">围绕 workspace 文件、历史任务和业务知识进行整理、摘要、审查和产物生成。</p></div>
|
||||
<div class="card card-accent"><h4>研发与技术支持</h4><p class="dim">分析代码、执行命令、读取日志、记录证据，为工程团队提供可追溯协作。</p></div>
|
||||
<div class="card card-accent"><h4>销售与客户成功</h4><p class="dim">沉淀客户上下文、准备沟通材料、跟踪待办，并与邮件日历等连接器协同。</p></div>
|
||||
<div class="card card-accent"><h4>内部 AI 能力平台</h4><p class="dim">让不同团队共用安全边界、工具管理、技能市场和多模型供应商策略。</p></div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>best fit: repeatable workflows with review requirements</span><span class="slide-number" data-current="5" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这里不要讲单一行业，而是讲适合 Beaver 的任务类型：高频、跨工具、需要留痕、结果需要验收。客户会自然映射到自己的场景，比如项目管理、运营报告、技术支持、知识库维护、客户成功和内部 AI 平台。关键是让客户看到 Beaver 能进入真实工作流。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Comparison">
|
||||
<p class="kicker">competitive edge</p>
|
||||
<h2 class="h2">优势对比：Beaver 补齐聊天、RPA 和通用 Agent 框架之间的空白。</h2>
|
||||
<div class="matrix mt-l">
|
||||
<div class="head">能力维度</div><div class="head">普通 AI 聊天</div><div class="head">传统自动化/RPA</div><div class="head">Beaver Agent Sandbox</div>
|
||||
<div class="rowhead">任务生命周期</div><div>以消息为中心</div><div>以固定流程为中心</div><div><span class="tag good">识别、执行、验收、复用闭环</span></div>
|
||||
<div class="rowhead">工具与文件</div><div>通常只生成建议</div><div>能执行但流程僵硬</div><div><span class="tag good">技能指导工具调用，过程留痕</span></div>
|
||||
<div class="rowhead">用户控制</div><div>缺少明确交付确认</div><div>改流程成本较高</div><div><span class="tag good">满意、修改、放弃进入任务状态</span></div>
|
||||
<div class="rowhead">经验沉淀</div><div>依赖聊天记录</div><div>依赖人工维护脚本</div><div><span class="tag good">成功任务转技能和长期记忆</span></div>
|
||||
<div class="rowhead">部署边界</div><div>SaaS 居多</div><div>企业内复杂集成</div><div><span class="tag good">Docker 多实例沙盒，适配私有部署</span></div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>differentiation: task closure + evidence + reusable skills</span><span class="slide-number" data-current="6" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这一页是客户很关心的“为什么不是已有方案”。普通聊天工具擅长生成内容，但缺少任务闭环和治理。RPA 能执行，但通常流程固定、维护成本高。通用 Agent 框架适合开发者搭系统，但客户还需要完整工作台、验收和管理界面。Beaver 的差异化在于把执行、证据、验收和经验沉淀做成一套产品。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Architecture For Customers">
|
||||
<p class="kicker">deployment model</p>
|
||||
<h2 class="h2">客户可理解的部署模型：入口统一，实例隔离，数据边界清晰。</h2>
|
||||
<div class="flow mt-l">
|
||||
<div class="flow-step"><span class="n">01</span><h4>认证门户</h4><p>用户注册、登录、进入模型配置引导。</p></div>
|
||||
<div class="flow-step"><span class="n">02</span><h4>授权服务</h4><p>管理账号、内部身份和 backend 注册。</p></div>
|
||||
<div class="flow-step"><span class="n">03</span><h4>部署控制</h4><p>为用户创建独立 app-instance 容器。</p></div>
|
||||
<div class="flow-step"><span class="n">04</span><h4>统一代理</h4><p>按实例域名把流量分发到对应容器。</p></div>
|
||||
<div class="flow-step card-accent"><span class="n">05</span><h4>用户实例</h4><p>前端、后端、workspace、文件、技能和配置在实例内运行。</p></div>
|
||||
</div>
|
||||
<div class="grid g3 mt-l">
|
||||
<div class="card card-accent"><h4>私有化友好</h4><p class="dim">最小部署基于 Linux/WSL2 + Docker，可放在企业自有环境或云主机。</p></div>
|
||||
<div class="card card-accent"><h4>实例级隔离</h4><p class="dim">每个 app-instance 有自己的 workspace、配置和运行数据边界。</p></div>
|
||||
<div class="card card-accent"><h4>供应商灵活</h4><p class="dim">模型 provider 可配置，支持后续成本、速度和质量策略。</p></div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>deployment: auth portal + deploy control + routed app instances</span><span class="slide-number" data-current="7" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
客户介绍中不需要展开所有代码细节，但要说明架构可信。Beaver 的多实例模式是：用户从认证门户进入，授权服务和部署控制创建独立实例，路由代理按域名分发流量。每个用户实例里有自己的前端、后端、workspace、技能和配置。客户能理解这是一个有边界的沙盒，而不是所有人混在一个共享会话里。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Trust And Governance">
|
||||
<p class="kicker">trust and control</p>
|
||||
<h2 class="h2">企业需要的不只是智能，还要可控、可解释、可治理。</h2>
|
||||
<div class="metric-grid mt-l">
|
||||
<div class="metric"><span>trace</span><b>证据链</b><p class="dim">任务、工具调用、产物和结果进入时间线。</p></div>
|
||||
<div class="metric"><span>review</span><b>验收</b><p class="dim">用户可接受、要求修改或放弃任务。</p></div>
|
||||
<div class="metric"><span>boundary</span><b>沙盒</b><p class="dim">文件与配置在实例边界内管理。</p></div>
|
||||
<div class="metric"><span>admin</span><b>工具治理</b><p class="dim">MCP 工具可测试、编辑、启停和审查。</p></div>
|
||||
</div>
|
||||
<div class="split mt-l">
|
||||
<div class="card card-accent"><h3>Unit tests</h3><p class="dim">历史 case 选择、双臂构造、工具模式分类、替身评分 payload、保真检查、低置信发布门禁。</p></div>
|
||||
<div class="card card-accent"><h3>Integration-style tests</h3><p class="dim">stub filesystem write、stub external write、candidate 同时改善真实 artifact 和 surrogate side effect。</p></div>
|
||||
<div class="card card-accent">
|
||||
<h3>对业务负责人</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>每个 AI 任务都有状态和产物。</li>
|
||||
<li>结果不是默认正确，需要用户确认。</li>
|
||||
<li>成功经验可沉淀为团队可复用能力。</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="card card-accent">
|
||||
<h3>对 IT / 安全团队</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>部署控制面不直接暴露公网。</li>
|
||||
<li>实例有独立 workspace 和配置边界。</li>
|
||||
<li>工具、模型和连接器可按企业策略逐步接入。</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>next: implement tasks 1-12 from the current plan</span><span class="slide-number" data-current="12" data-total="13"></span></div>
|
||||
<div class="deck-footer"><span>governance: evidence, acceptance, isolation, admin controls</span><span class="slide-number" data-current="8" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这一页收束到交付标准。测试不只测 happy path，而是围绕风险边界：模型兼容、case 选择、双臂构造、工具模式聚合、替身 payload、保真检查、发布门禁，以及混合工具场景。我们需要证明这套评估不仅能生成报告，而且能正确处理安全工具、外部写入和低置信度边界。
|
||||
这一页强调企业采购最关心的风险问题。业务负责人关心能不能交付，IT 和安全团队关心能不能管控。Beaver 的回答是：任务有证据链，结果有验收，实例有边界，工具和连接器可治理。这样客户会觉得它不是一个不受控的 AI 黑盒，而是一个可纳入企业管理的系统。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide center tc" data-title="Questions">
|
||||
<div>
|
||||
<div class="center-mark">Q</div>
|
||||
<h2 class="h2 mt-m">Questions</h2>
|
||||
<p class="lede" style="margin-left:auto;margin-right:auto;">技能发布前，不只要看草稿写得好不好，还要看它在历史任务里做了什么、没做什么、敢不敢相信。</p>
|
||||
<div class="row mt-l" style="justify-content:center">
|
||||
<span class="tag good">behavior evidence</span>
|
||||
<span class="tag">tool coverage</span>
|
||||
<span class="tag warn">confidence gates</span>
|
||||
<span class="tag">draft preservation</span>
|
||||
<section class="slide" data-title="Learning Loop">
|
||||
<p class="kicker">learning moat</p>
|
||||
<h2 class="h2">长期优势：越用越会做，把企业经验变成智能体资产。</h2>
|
||||
<div class="pipeline mt-l">
|
||||
<div class="phase card-accent"><span class="tag">memory</span><h3>长期记忆</h3><p class="dim">沉淀用户偏好、组织知识、历史任务、文件产物和工具经验。</p></div>
|
||||
<div class="phase card-accent"><span class="tag">skills</span><h3>技能库</h3><p class="dim">把被认可的任务方法转为技能候选、草稿、审核和发布。</p></div>
|
||||
<div class="phase card-accent"><span class="tag">marketplace</span><h3>市场与分发</h3><p class="dim">让团队安装、复用和管理已验证的技能与工具能力。</p></div>
|
||||
</div>
|
||||
<div class="panel mt-l">
|
||||
<span class="tag good">客户价值</span>
|
||||
<p class="lede mt-s">第一次交付依赖人工指导，第二次开始复用技能和记忆，长期形成企业自己的 AI 工作方法库。</p>
|
||||
</div>
|
||||
<div class="deck-footer"><span>compounding advantage: accepted work becomes reusable capability</span><span class="slide-number" data-current="9" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
客户会问：这个系统的长期壁垒是什么？答案是学习闭环。普通工具每次都从头开始，而 Beaver 会把被用户认可的任务经验沉淀为技能，把稳定信息沉淀为记忆。后续类似任务可以自动激活已有方法。这让企业的 AI 能力随着使用增加，而不是永远停留在通用模型层。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Readiness">
|
||||
<p class="kicker">current readiness</p>
|
||||
<h2 class="h2">当前已具备的可展示能力，足够支撑客户试点。</h2>
|
||||
<div class="matrix mt-l">
|
||||
<div class="head">能力</div><div class="head">当前状态</div><div class="head">客户看到什么</div><div class="head">商业价值</div>
|
||||
<div class="rowhead">任务执行闭环</div><div><span class="tag good">已完成</span></div><div>任务列表、详情、时间线、验收操作</div><div>从回答变成可交付结果</div>
|
||||
<div class="rowhead">工具与证据</div><div><span class="tag good">已具备</span></div><div>文件、终端、网页、技能、定时任务等工具调用记录</div><div>可审计、可复盘</div>
|
||||
<div class="rowhead">多智能体协作</div><div><span class="tag good">已具备</span></div><div>复杂任务拆分、子任务结果汇总</div><div>处理多阶段复杂工作</div>
|
||||
<div class="rowhead">技能沉淀</div><div><span class="tag good">已具备</span></div><div>候选、草稿、评审、发布链路</div><div>形成企业技能库</div>
|
||||
<div class="rowhead">长期记忆</div><div><span class="tag warn">底层已完成，待产品化接入</span></div><div>后续展示记忆管理台和检索轨迹</div><div>越用越懂业务</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>pilot-ready modules plus roadmap for memory/productization</span><span class="slide-number" data-current="10" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
这一页要避免过度承诺，同时告诉客户可以试点。任务闭环、工具调用、证据留存、多智能体、技能沉淀这些已经具备展示基础。长期记忆底层能力已经完成，但仍需要接入主产品链路和 UI，因此对客户可以讲成下一阶段重点。这样既展示实力，也保持可信边界。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Business Value">
|
||||
<p class="kicker">business value</p>
|
||||
<h2 class="h2">客户收益：更快交付、更低风险、更强复用。</h2>
|
||||
<div class="metric-grid mt-l">
|
||||
<div class="metric"><span>speed</span><b>交付提速</b><p class="dim">将多步骤知识工作从人工串联变成 AI 协作执行。</p></div>
|
||||
<div class="metric"><span>quality</span><b>过程透明</b><p class="dim">任务时间线和证据链降低黑盒风险。</p></div>
|
||||
<div class="metric"><span>reuse</span><b>经验复用</b><p class="dim">技能和记忆让团队避免重复提示和重复摸索。</p></div>
|
||||
<div class="metric"><span>control</span><b>成本可控</b><p class="dim">模型供应商可配置，为后续质量/成本路由打基础。</p></div>
|
||||
</div>
|
||||
<div class="split mt-l">
|
||||
<div class="card card-accent">
|
||||
<h3>适合先做试点的部门</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>需要频繁生成和修改交付物的项目团队。</li>
|
||||
<li>重复处理文件、报告和知识资料的运营团队。</li>
|
||||
<li>需要审计工具调用和任务证据的技术团队。</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="card card-accent">
|
||||
<h3>成功指标建议</h3>
|
||||
<ul class="clean mt-m">
|
||||
<li>任务交付时间下降。</li>
|
||||
<li>重复工作模板化比例提升。</li>
|
||||
<li>人工修改轮次下降。</li>
|
||||
<li>可追溯任务报告覆盖率提升。</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>Beaver Skill Replay Eval</span><span class="slide-number" data-current="13" data-total="13"></span></div>
|
||||
<div class="deck-footer"><span>value: speed, governance, reuse, model flexibility</span><span class="slide-number" data-current="11" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
最后一页只留核心判断，方便收尾和进入问答。可以用一句话结束：Replay Eval 让技能发布从“相信生成结果”变成“审查行为证据”。然后邀请大家针对工具策略、隔离环境、替身判断、发布门禁或 UI 展示提问。
|
||||
这里把商业价值说得具体一点。不要只说提升效率，而要拆成可衡量指标：任务交付时间、重复工作模板化比例、修改轮次、可追溯报告覆盖率。客户如果要做试点，也需要这些指标判断是否成功。Beaver 的核心收益是更快交付、更低风险、更强复用。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide" data-title="Pilot Plan">
|
||||
<p class="kicker">pilot plan</p>
|
||||
<h2 class="h2">建议落地方式：先选高价值场景，4 步完成客户试点。</h2>
|
||||
<div class="roadmap mt-l">
|
||||
<div class="item"><span>01</span><b>场景选择</b><p>选择一个高频、跨工具、需要验收的部门流程，例如周报、方案交付或文件处理。</p></div>
|
||||
<div class="item"><span>02</span><b>私有部署</b><p>在客户环境部署 Beaver，配置模型 provider、用户入口和实例域名。</p></div>
|
||||
<div class="item"><span>03</span><b>工具接入</b><p>接入文件、搜索、邮件日历、MCP 工具或企业内部系统。</p></div>
|
||||
<div class="item"><span>04</span><b>技能沉淀</b><p>把试点成功流程整理成技能，建立可复用的企业 Agent 模板。</p></div>
|
||||
</div>
|
||||
<div class="panel mt-l">
|
||||
<span class="tag warn">推荐节奏</span>
|
||||
<p class="lede mt-s">第一阶段先做 2-4 周试点，验证一个部门流程；第二阶段扩展连接器、权限策略和技能市场；第三阶段接入长期记忆管理。</p>
|
||||
</div>
|
||||
<div class="deck-footer"><span>pilot path: scenario, deploy, integrate, reuse</span><span class="slide-number" data-current="12" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
客户方案要给落地路径。建议不要一开始全公司铺开，而是先挑一个高价值流程，2 到 4 周试点。先部署系统和模型，接入必要工具，再把成功流程沉淀成技能。试点成功后再扩展连接器、权限策略、市场和长期记忆管理。这样客户知道下一步怎么做。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="slide center tc" data-title="Closing">
|
||||
<div>
|
||||
<div class="center-mark">B</div>
|
||||
<h2 class="h2 mt-m">Beaver Agent Sandbox</h2>
|
||||
<p class="lede" style="margin-left:auto;margin-right:auto;">把企业 AI 从“会回答”升级为“能执行、可验收、可追踪、会复用”的智能体工作台。</p>
|
||||
<div class="row mt-l" style="justify-content:center">
|
||||
<span class="tag good">任务闭环</span>
|
||||
<span class="tag">过程证据</span>
|
||||
<span class="tag warn">私有沙盒</span>
|
||||
<span class="tag">技能沉淀</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="deck-footer"><span>Commercial proposal deck</span><span class="slide-number" data-current="13" data-total="13"></span></div>
|
||||
<aside class="notes">
|
||||
最后一页用于收束。可以把一句话再重复一遍：Beaver 让企业 AI 不止停留在回答，而是进入可执行任务、可验收结果、可追踪证据和可复用经验。随后进入客户问题讨论：他们最想先试点哪个场景、已有模型和工具是什么、部署环境有什么约束。
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user