English mirror

This English page is generated from the current Chinese documentation so every route, anchor, code sample, and language switch stays available on agently.tech. Human-edited English copy can replace this generated body page by page.

Read the Chinese source page

从场景到能力选型

官网用户通常不是来阅读一套内部方法论，而是带着一个业务问题来判断：这个框架能不能帮团队少走弯路、更快交付、上线后还能管得住。

这一页按场景选能力。每个场景都先说业务上要交付什么，再说 Agently 负责补哪条工程链路。

先判断业务要拿到什么

业务目标	业务方想看到	开发团队要补齐	Agently 入口
把一段输入变成可消费字段	工单、表单、风险项、摘要、证据	字段、类型、必填项、校验、retry、最终数据读取	输出控制、模型响应
在完整结果出来前看到进展	前端卡片逐步填充、报告章节逐段出现	instant 字段流、临时 UI 状态、最终 get_data() 持久化	模型响应、TriggerFlow 模型集成
让模型调用业务能力	查状态、查数据库、发通知、调用控制器	Action schema、可见能力范围、调用日志、错误语义	Actions、Action Runtime
接入 MCP、脚本或专业工具	复用已有生态能力，但不失控	Host 侧权限、脱敏、审计；受控执行环境生命周期	MCP、Execution Environment
任务出现分支、等待、审批和恢复	每一步在哪里、为什么停、谁能续跑	execution id、runtime stream、pause/resume、close snapshot	TriggerFlow
一个任务需要多个专业角色协作	风险、事实、编辑、执行等角色各自产出可复核结果	角色化 Agent、Sub-Flow、Workspace 拓扑、结构化汇总	多角色协作与子流程 Playbook
系统要主动推进任务或回推提醒	定时日报、审批提醒、外部事件触发、IM 消息回推	scheduler / webhook / queue 与 Agently execution 边界	交互层与主动任务 Playbook
任务需要跨轮保留证据	上次结论、报告、下载物、规则和检查点可追溯	Workspace record / artifact / checkpoint，按目标召回 ContextPack	Workspace、Context Engineering

常见场景怎么落到能力组合

客服、运营和内部工单

业务目标是让用户一句话进入工单系统：识别意图、判断优先级、生成下一步动作，必要时查询业务状态或通知负责人。

推荐组合：

1. 用 output schema 固定 intent、priority、next_step、customer_reply。
2. 用 instant stream 让前端先显示工单卡片的生成过程。
3. 用 Actions 挂接查询、创建工单、通知等能力，所有动作都有调用记录。
4. 涉及审批、升级、等待回调时，再进入 TriggerFlow。

先不要做的事：不要把模型自然语言直接写进工单字段；不要把全部工具一次性暴露给模型。

行业日报、研究报告和资料整理

业务目标是把“一个主题”交付成可继续编辑、可复核来源的报告，而不是只让模型写一段总结。

推荐组合：

1. 用 TriggerFlow 显式拆出选题、栏目规划、搜索、候选筛选、正文浏览、摘要、渲染。
2. 用结构化输出固定标题、链接、摘要、推荐理由、栏目导语。
3. 用 sub-flow / 并发处理多个栏目或候选材料。
4. 把中间材料、最终 Markdown、PDF 或截图存成 Workspace artifact。

先不要做的事：不要把网页搜索、浏览、摘要和渲染塞进一个长 prompt；也不要让流程结果只存在控制台日志里。

文档审查、合同分析和规则核对

业务目标是让系统说清楚“哪类文档、有哪些风险、证据在哪里、下一步要谁处理”。

推荐组合：

1. 先做路由：识别文档类型、业务场景和处理路径。
2. 再做任务分解：抽取条款、核对规则、列出风险、生成建议。
3. 用 Reflection 或二次模型 judge 检查结果是否满足规则。
4. 高风险结论进入人工确认或 TriggerFlow pause/resume。
5. 原文、证据片段、审查报告放进 Workspace，后续轮次按目标召回。

先不要做的事：不要用关键词或正则做语义路由；不要把“模型觉得没问题”当作最终验收。

当文档任务需要法务、财务、业务、编辑等多个视角时，不要让多个 Agent 自由聊天。把每个视角设计成角色子流：输入原始材料和共享证据，输出结构化 finding、approval flag、artifact ref，再由父流程汇总。

自然语言控制业务对象

业务目标是让用户用自然语言操作设备、后台对象或业务流程，同时系统能拒绝越权或不支持的请求。

推荐组合：

1. 用 output schema 让模型先输出动作计划、目标对象、参数和拒绝理由。
2. 用 Actions 限定可调用控制器和状态读取函数。
3. 用确定性代码消费模型计划，执行前做权限、参数和状态检查。
4. 用 runtime stream 把“计划、执行、结果、拒绝”展示给用户。

先不要做的事：不要让模型输出一段文字后由前端临时猜要执行哪个按钮；也不要让模型直接拼接工具 API 请求。

专业工作台和复杂工具链

业务目标是把专业需求推进到可执行方案，例如设计、分析、质检、运维、数据处理或工程工具操作。

推荐组合：

1. 模型负责生成结构化草案、可解释计划或候选方案。
2. 确定性 gate 检查硬规则，例如短路、缺字段、权限、预算、格式、依赖。
3. 受控执行环境负责脚本、MCP server、浏览器、SQLite、Node.js 或专业工具依赖。
4. TriggerFlow 串起规划、校验、替代方案、执行、总结和人工确认。
5. Workspace 保存草案、校验报告、工具输出和最终证据。

先不要做的事：不要用 prompt 代替硬规则校验；不要把专业工具进程藏在 Action executor 里偷偷启动。

定时、提醒和主动流程

业务目标是让系统在没有用户实时发起请求时也能推进工作：每天生成日报、审批超时提醒、外部系统状态变化后继续流程、定期巡检或补偿失败任务。

推荐组合：

1. 应用系统拥有 scheduler、webhook、queue、任务表和幂等键。
2. Agently TriggerFlow 承接具体流程：开始、分支、等待、恢复、close snapshot。
3. runtime stream 产生产品事件，推给 Web UI、SSE、WebSocket 或 IM 网关。
4. Event Center / RuntimeEvent 记录运行事实，供运维、审计和回放使用。

先不要做的事：不要把定时循环写进 HTTP request handler；不要把 RuntimeEvent 当成前端协议；不要在没有 task_id / execution_id 的情况下做主动任务。

能力包、团队规范和可复用经验

业务目标是让团队积累的做法可以被选择、加载和执行，而不是散落在 prompt、脚本和 README 里。

推荐组合：

1. 用 Skill 表达可复用行为资产：guidance、资源、工具依赖、workflow 描述和校验规则。
2. 用选择策略决定哪些 Skill 进入当前任务，命中失败或信任拦截要留下原因码。
3. 真正执行时回落到 Actions、ExecutionEnvironment、Dynamic Task 或 TriggerFlow。
4. 多个 Skill 有依赖时，用 Dynamic Task / TaskDAG 表达计划图。

先不要做的事：不要把 Skill 当成第二套 Tool、Workflow 或沙箱；Skill 负责“可被选择的行为资产”，执行边界仍由运行时能力负责。

一个简单判断顺序

新场景进来时，可以按这个顺序和业务方对齐：

1. 最终要进入业务系统的字段是什么？
2. 用户是否需要在完整结果前看到过程？
3. 模型是否需要调用外部能力？
4. 这些能力有没有权限、脱敏、审计或环境生命周期问题？
5. 流程是否有分支、并发、等待、审批、恢复或过程展示？
6. 哪些产物、规则、证据和检查点要跨轮保留？
7. 上线后用什么事件、日志、评估或回放证明系统在正常工作？

如果第 1 个问题都还答不清，先不要谈多 Agent、复杂工作流或 Skill 生态。先把结果契约定下来，后面的能力才有稳定基础。

和项目证据对照

项目类型	证明的场景	Agently 承担的职责
Daily News Collector	主题到日报报告	流程编排、搜索/浏览、结构化摘要、报告渲染
Talk to Control	自然语言控制业务对象	动作计划、控制器边界、拒绝越权、过程反馈
AgentlyTextParser	长文抽取和证据定位	分段处理、字段抽取、引用定位、结果汇总
EDA Agent Final	专业工具链助手	结构化草案、确定性校验、受控工具执行、运行证据

读案例时先看“它帮助客户交付什么”，再回到能力页看 API。这样能避免从框架名词出发，把简单问题做复杂。