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.
从 PoC 到上线
AI Agent 的 PoC 通常很快：一个 prompt、一个模型调用、几段 demo 输出就能展示价值。真正难的是上线：接口要稳定，行动要受控，长流程要能恢复，产物要能复核，版本更新后不能让文档和示例继续掉队。
Agently 的生产路径可以按层验收。
如果还在做系统方案，而不是上线检查，先读 企业 Agent 系统设计路线图。那一页按工程骨架、智能回路、外部行动、复杂任务、长程状态和生产治理组织；本页只回答每一层进入生产前要怎么验收。
逐层验收
| 阶段 | 目标 | 验收问题 | 文档入口 |
|---|---|---|---|
| 0. 最小原型 | 跑通模型和业务输入 | 模型配置是否可复现？失败时是否清楚？ | 快速开始、模型设置 |
| 1. 稳定输出 | 让结果能被系统消费 | 字段、类型、必填项、校验和 retry 是否明确？ | 输出控制 |
| 2. 流式体验 | 让 UI 和服务先看到进展 | 是否用 instant stream 做临时 UI，并用最终 get_data() 写入业务状态？ | 模型响应 |
| 3. 服务化 | 暴露 HTTP / SSE / WebSocket | 接入层是否只做请求校验、调用和返回？是否优先 async？ | Async First、FastAPI 服务封装 |
| 4. 外部行动 | 调业务函数、MCP、搜索、浏览或工具 | 能力 schema、可见范围、日志、错误和审计是否清楚？ | Actions 概览 |
| 5. 受控环境 | 托管 MCP server、脚本或沙箱依赖 | 生命周期、权限、健康检查和失败语义是否明确？ | Execution Environment |
| 6. 长流程 | 处理分支、并发、审批、等待和恢复 | execution id、runtime stream、pause/resume、close snapshot 是否能被外部系统使用？ | TriggerFlow |
| 7. 多角色协作 | 让多个专业视角共同处理同一业务任务 | 角色职责、Sub-Flow、Workspace 拓扑和汇总字段是否明确？ | 多角色协作与子流程 Playbook |
| 8. 交互层 | 把过程交给用户、前端或 IM | 产品事件、SSE/WebSocket/IM、等待提示和最终状态是否分开？ | 交互层与主动任务 Playbook |
| 9. 主动任务 | 定时、webhook、queue 或 worker 推进任务 | scheduler、幂等、任务表和 execution 恢复是否有 owner？ | 交互层与主动任务 Playbook |
| 10. 状态与证据 | 保留产物、观察、决策和检查点 | 大块内容是否存 Workspace artifact，执行状态是否只留 ref？ | Workspace、长程任务状态与恢复 Playbook |
| 11. 观测与评估 | 证明系统运行事实和质量变化 | 是否有 RuntimeEvent、DevTools、评估用例或回放证据？ | 观测概览、生产治理 Playbook |
最小企业拓扑
一个可上线的企业 Agent 服务通常至少拆成这些角色：
| 模块 | 负责什么 |
|---|---|
| Gateway / API | 认证、租户、请求校验、HTTP/SSE/WebSocket |
| Agent Core | Agent definition、AgentExecution、Prompt / output contract |
| Tool Adapters | 业务 API、MCP client、本地函数、搜索、浏览 |
| Execution Environment | MCP server、脚本、数据库、浏览器、沙箱等运行依赖 |
| Flow Orchestrator | TriggerFlow definitions、executions、runtime stream、pause/resume |
| Interaction Layer | 产品过程事件、SSE/WebSocket/IM 网关、等待提示和最终通知 |
| Scheduler / Worker | 定时触发、webhook、queue、幂等和主动任务推进 |
| Workspace Store | observation、artifact、decision、checkpoint 和 ContextPack |
| Eval / Observer | RuntimeEvent、DevTools、评估用例、回放和质量判断 |
不一定一开始就拆成多个仓库或服务，但代码职责应该按这些 owner 分开。否则 PoC 越成功，后面越难交给业务系统长期运行。
上线前检查清单
| 检查项 | 通过标准 |
|---|---|
| 输出契约 | 业务系统消费的是结构化 data，不是自然语言片段 |
| 流式边界 | instant stream 只做临时 UI / 进度状态，最终持久化读最终 data |
| 行动边界 | 所有可调用能力都在 Actions / MCP / built-in Actions 中注册并有记录 |
| 环境边界 | 脚本、MCP server、浏览器、SQLite、Node.js 等依赖有受控环境 owner |
| 权限与审批 | 高风险或不可回滚动作有 policy、审批或 fail-closed 路径 |
| 长流程 | 需要等待、恢复或人工介入的流程有 execution handle 和 interrupt 语义 |
| 多角色协作 | 角色化 Agent、Sub-Flow、Workspace 拓扑和结构化汇总字段清楚 |
| 交互层 | UI/IM 消费的是产品事件，不是 parser path、chunk 名或 RuntimeEvent |
| 主动任务 | scheduler / webhook / queue 与 HTTP request handler 分离，任务推进有幂等键 |
| 状态 | 大块产物、下载物、报告和日志不塞进 prompt 或 execution state |
| 恢复 | checkpoint、execution save/load、runtime resource 重新注入和外部 resume 入口清楚 |
| 观测 | 请求、Action、Execution Environment、TriggerFlow 关键事件可追踪 |
| 回归 | 有代表性输入、输出契约检查、业务规则校验或模型 judge 评估 |
| 治理 | 成本、timeout、重试、幂等、安全和审计各有 owner |
| 更新 | release / docs / examples / Agently-Skills 指引能同步更新 |
何时可以先不做
| 能力 | 可以暂缓的条件 |
|---|---|
| TriggerFlow | 只有一次请求，没有分支、并发、等待、恢复或过程流 |
| 多角色协作 | 一个 AgentExecution 已经能完成稳定结构化结果 |
| 主动任务 | 任务只由用户请求即时触发，不需要定时、webhook 或 worker 推进 |
| Dynamic Task | 任务图不是模型或业务系统提交的数据 |
| Workspace | 没有跨轮证据、产物、检查点和长期上下文 |
| Execution Environment | 只调用普通本地函数或已托管的业务 API |
| DevTools / Eval | PoC 初期可以先用日志和人工审查，但上线前必须补运行证据 |
生产路径不是一次性把所有能力打开。更好的做法是：每新增一层能力，就补一层可验证证据。
Playbook 入口
- 任务会跨轮、等待审批、恢复或复核产物：长程任务状态与恢复 Playbook
- 一个任务需要多个专业角色协作：多角色协作与子流程 Playbook
- 过程要推给前端/IM，或系统要主动触发任务：交互层与主动任务 Playbook
- 准备上线、发布前回归、接日志和审计：生产治理 Playbook