企业 Agent 能力边界
企业 Agent 不是一个“大 prompt”。它通常由多层 owner 协作完成：接入层负责服务边界，模型请求层负责判断和结果契约，运行时层负责行动，工作流层负责生命周期，状态层负责长期证据。
Owner 对照
| 层 | 它负责什么 | 它不负责什么 | Agently 入口 |
|---|---|---|---|
| Gateway / API | 鉴权、租户、HTTP/SSE/WebSocket、请求校验、路由到业务能力 | 不写 prompt，不直接管理模型决策 | FastAPI 服务封装 |
| AgentExecution | 一次 Agent run 的输入、目标、输出契约、流、meta 和诊断 | 不替代长期 workflow lifecycle | Agent 自动编排 |
| Output Control | 字段、类型、必填项、校验、retry、instant stream | 不负责调用外部能力 | 输出控制 |
| Model Response | 同一次响应的 text / data / meta / stream 复用 | 不重复发起模型请求拿不同视图 | 模型响应 |
| Actions | 模型可调用能力、参数 schema、调用记录和结果归一 | 不管理长生命周期资源 | Actions 概览 |
| MCP | 标准化能力供应、发现和调用协议 | 不替 Host 做业务编排、权限裁剪、脱敏和审计 | MCP |
| ExecutionEnvironment | MCP server、Bash/Python/Node/SQLite/浏览器/沙箱等依赖的生命周期 | 不决定一个业务任务该怎么走 | Execution Environment |
| Skills Executor | 可复用行为资产的发现、选择、加载和策略执行 | 不成为第二套 Actions / TriggerFlow / sandbox | Skills Executor |
| Dynamic Task | 模型或应用提交的 DAG 数据校验和执行 | 不替代稳定工作流定义 | Dynamic Task |
| TriggerFlow | 分支、并发、事件、runtime stream、pause/resume、save/load、close snapshot | 不替代输出 schema，也不存大块长期记忆 | TriggerFlow 概览 |
| Workspace / Recall | observation、artifact、decision、checkpoint、ContextPack | 不让模型自动决定什么都该记住 | Workspace |
| Interaction Layer | 产品过程事件、SSE/WebSocket、IM 网关、等待提示和消息回推 | 不决定 workflow 控制流，不替代观测系统 | 交互层与主动任务 Playbook |
| Scheduler / Worker | 定时、webhook、queue、主动任务推进、幂等和任务表 | 不写 prompt，不把业务流程藏在循环里 | 交互层与主动任务 Playbook |
| Observability | RuntimeEvent、Event Center、DevTools、评估和调试 | 不改变 flow 控制流 | 观测概览 |
MCP 的正确位置
MCP 的价值是让能力提供方和智能应用方分工：Server 暴露能力，Client 管连接，Host 决定怎么用。
企业系统通常仍要自己掌握 Host 逻辑，原因很具体：
- 当前 end-user 的身份和 token 要从应用侧透传到能力侧；
- 不同角色看到的工具集合应该不同，不能让模型先看全量再反复被拒绝；
- 敏感字段应该在进入模型上下文前脱敏或聚合；
- 审计既要记录能力侧访问，也要记录 Host 为什么暴露、选择和调用了这项能力。
所以官网里讲 MCP 时，不应把它写成“接上就完成治理”。更准确的表达是：MCP 让能力供应标准化；Agently 的 Actions / ExecutionEnvironment / TriggerFlow / Observability 帮应用侧把这些能力放进可控运行链路。
Skill 的正确位置
Skill 是可复用的行为资产。它可以包含 guidance、资源索引、工具依赖、脚本声明、workflow 描述、输出和校验规则。
但 Skill 本身不是：
- 不是 Tool：Tool 是原子调用，Skill 可以描述多步行为；
- 不是 Prompt：Prompt 是文本片段，Skill 是可选择、可加载、可执行的行为包；
- 不是 Workflow：Workflow 是执行生命周期，Skill 可以映射到 TriggerFlow 或 Dynamic Task；
- 不是沙箱：脚本和第三方能力仍要通过 Actions / ExecutionEnvironment 进入受控执行。
多角色协作的正确位置
多角色协作不是一个和 TriggerFlow 平级的新生命周期。它是应用系统的拓扑设计：
- 角色化 Agent 负责专门判断，例如风险、事实、编辑、执行；
- Sub-Flow 负责隔离每个角色的流程和可测试边界；
- Workspace 负责共享/独立证据和产物；
- 父 TriggerFlow 负责分派、等待、汇总、审批和最终交付。
所以官网里讲多 Agent 时，重点应该是“角色职责、交接字段、状态拓扑和汇总验收”，而不是“同时启动几个模型请求”。
常见边界错误
| 错误 | 后果 | 修正 |
|---|---|---|
| 用关键词或正则做业务路由 | 语义边界错，复杂规则难维护 | 用模型请求 + output schema 返回 category、evidence、dispatch hint |
| 把模型输出当控制流直接执行 | 越权、参数错、无法审计 | 先结构化输出，再由确定性代码消费 |
| 把 Action 当工作流 | 看不到阶段、等待、恢复和并发边界 | 有生命周期就进入 TriggerFlow |
| 把 RuntimeEvent 当流程信号 | 观测和控制流混淆 | 改变流程用 TriggerFlow signal；记录事实用 RuntimeEvent |
| 把 RuntimeEvent 当产品 UI 协议 | 前端和运维日志耦合，字段不稳定 | 产品界面消费 runtime stream 映射后的业务事件 |
| 把多 Agent 当成自由聊天 | 无法测试、无法审计、无法汇总 | 角色化 Agent + Sub-Flow + Workspace 拓扑 |
| 把定时任务写进 HTTP handler | 请求生命周期和主动任务耦合，恢复困难 | scheduler / queue / worker 拥有触发源，Agently execution 承接流程 |
| 把大块报告或日志塞进 execution state | 状态膨胀、恢复困难 | 存 Workspace artifact，state 只保留 ref 和摘要 |
| 把服务层写成业务核心 | API 变难测，流程难迁移 | Router 只做接入、校验和返回；业务能力留在 Agent/flow/service 层 |
判断顺序
一个新场景进来时，按下面顺序判断：
- 先问：最终要交付给业务系统的字段是什么？
- 再问：模型需要调用哪些外部能力，这些能力是否有权限和审计边界？
- 再问：执行是否需要托管环境、沙箱、MCP server 或浏览器生命周期？
- 再问：流程是否有分支、并发、等待、恢复、审批或过程展示？
- 再问：是否需要多个专业角色共同产出，角色之间怎么交接？
- 再问：产品界面、IM 或主动任务是否需要看到过程和等待状态？
- 再问：哪些产物和证据要跨轮保留？
- 最后问：上线后怎么观察、评估和回放？
这套顺序能避免一上来陷入“选哪个 Agent 名词”的讨论。