Appearance
Workflow 把“怎么做”写进程序；Agentic 则把“怎么做”的一部分，留到程序运行时决定，文章末尾也会对workflow和Agentic两种范式进行对比，具体见第十节
我们先从一个并不复杂的需求说起。
产品经理希望构建一个企业研究助手。用户输入一家公司的名称，系统需要收集近期新闻、财务数据和行业信息，最后生成一份竞争分析报告。
最自然的实现方式，是先把任务拆成若干步骤：
text
查询企业信息
↓
查询财务数据
↓
搜索行业新闻
↓
选择竞争对手
↓
生成对比分析
↓
输出报告第一版通常很快就能运行起来。
接下来，产品经理会提出更多要求：
- 财务数据出现异常时，需要进一步阅读财报；
- 不同来源的数据不一致时，需要交叉验证；
- 如果企业正在扩展海外业务，需要补充当地市场与政策信息；
- 如果某个竞争对手不再具有可比性，需要重新选择；
- 如果证据不足，不能直接生成确定性结论。
于是，原来的直线流程开始出现分支：
text
财务数据是否异常？
├── 否 → 继续
└── 是 → 查询财报附注
数据是否冲突？
├── 否 → 继续
└── 是 → 查询第二数据源
是否涉及海外业务？
├── 否 → 继续
└── 是 → 查询海外市场再往后，分支会继续嵌套。某些判断需要模型完成，某些步骤需要循环，某些错误需要重试，还有一些动作需要用户确认。
这时，我们很容易得出一个结论：流程还不够完整，需要继续增加节点。
但更值得追问的是：
这真的是一个“流程不够完整”的问题吗？
也许不是。
研究人员在开始调研之前，同样无法准确决定自己要搜索多少次、会遇到什么异常、是否需要更换分析方向，对于这类开放任务，合理的执行路径往往只有在任务运行过程中才能逐渐确定。
任务路径本身，也是任务求解过程的一部分。
这正是 Workflow 与 Agentic 两种开发范式开始分叉的地方。
1. 已知路径
Workflow 解决的是如何可靠地执行一条已知路径。
以 Graph 类框架为例，开发者首先把业务拆解成离散节点，再定义节点之间的连接关系，通过共享状态驱动流程运行。
它的基本结构可以表示为：
text
State
↓
Node A
↓
Edge 根据 State 选择路径
├── Node B
└── Node C如果稍微形式化一些，可以写成：
text
state' = node(state)
nextNode = edge(state')节点完成工作，边决定下一步。
大模型当然也可以出现在这个过程中。
例如：
- “用户意图分类”节点可以调用模型；
- “合同风险识别”节点可以调用模型；
- “是否需要转人工”可以由模型判断；
- 条件边也可以根据模型的结构化输出来选择分支。
但在这种结构中，模型主要解决的是局部认知问题：
- 这封邮件属于什么类别？
- 这段内容是否违规？
- 这份合同包含哪些风险？
- 这一次应该进入哪条预置分支？
整个应用的宏观结构依然由开发者控制。
节点有哪些、节点如何连接、哪些路径允许出现、流程何时终止，基本在设计阶段已经确定。
换句话说：
模型可以决定某个节点的输出，但流程图决定应用下一步能去哪里。
这种方式有非常明确的优势。
执行路径清晰，状态容易检查，失败可以定位到具体节点，调用成本和执行时延也相对容易估算。节点边界还可以自然形成检查点，用于重试、暂停、恢复和人工介入。
因此，Workflow 并不是一种过时的开发方式。
对于报销审批、工单流转、内容审核、文档处理、订单状态机等路径相对明确的任务，它往往仍然是最合适的方案。
真正的问题出现在另一类任务中：
当开发者无法在设计阶段穷举所有合理路径时，继续增加节点和分支，未必是在解决问题，也可能只是在用流程图模拟一个本应动态决策的过程。
2. 运行时决策
很多人把 Agentic 理解成“模型可以调用工具”。
但 Tool Calling 本身并不足以构成 Agentic。
一个固定工作流中的模型节点，同样可以调用搜索接口：
text
固定节点：搜索资料
↓
模型生成查询词
↓
调用搜索 API
↓
把结果传递给下一个固定节点这里有模型，也有工具，但下一步仍然由流程图决定。
Agentic 更本质的变化是：
模型开始参与应用控制流的生成。
Workflow 的控制方式可以简化为：
text
next_step = developer_defined_flow(current_state)而 Agentic 更接近：
text
next_action = model(
goal,
context,
observations,
available_tools,
constraints
)模型根据当前目标和状态选择行动，环境执行这个行动，再把执行结果反馈给模型：
text
行动
↓
环境执行
↓
获得观察
↓
重新决策
└──────↺如果进一步形式化，可以写成：
text
aₜ = πθ(goal, contextₜ, toolsₜ, constraintsₜ)
observationₜ₊₁ = environment(aₜ)
contextₜ₊₁ = update(contextₜ, aₜ, observationₜ₊₁)其中：
goal表示任务目标；context表示模型目前知道什么；tools表示模型可以采取哪些行动；constraints表示行动边界；environment表示文件系统、数据库、浏览器、API 或其他 Agent；observation表示行动完成后，环境返回了什么。
Agent 的行为，就是这个循环不断展开的结果。
因此，一次 Agent 任务并不等于一次模型调用。
它可能经历：
text
理解目标
↓
搜索资料
↓
阅读网页
↓
发现数据矛盾
↓
更换来源重新搜索
↓
调用代码工具计算指标
↓
发现新的异常
↓
修改原来的分析计划
↓
生成最终报告这条路径并不是在程序启动之前完整存在的。
它是在模型与环境不断交互的过程中逐渐形成的。
这也是 Agentic 与普通 LLM 应用之间最重要的差异：模型不再只是计算节点，也进入了应用的控制回路。
3. ReAct 循环
AgentScope 的关键，并不是提供了一个名为 Agent 的类。
它真正重要的地方，是把推理、行动与观察构成的循环，提升为框架中的一等抽象。
在 AgentScope 中，一次 Agent 调用并不一定对应一次模型请求。调用启动的是一轮完整的任务执行过程，内部可能包含多次模型推理和工具调用。
可以把它简化为：
text
用户输入目标
↓
组装当前上下文
↓
调用模型
↓
模型输出什么？
┌───┴──────────┐
│ │
最终回答 工具调用
│ ↓
结束 权限检查
↓
执行工具
↓
获得结果
↓
写回当前上下文
└──────→ 再次调用模型这就是典型的 Reasoning-Acting Loop。
模型并不只是生成文本，它还可以生成行动请求。例如：
text
调用 search_web，查询企业最近六个月的经营新闻工具执行完成后，结果会被写回上下文：
text
企业最近一个季度销量上升，但终端促销幅度明显扩大。模型再基于这个新观察判断下一步：
- 查询利润率变化；
- 阅读财报；
- 调查价格战；
- 对比竞争对手；
- 直接生成阶段性结论。
这里的重点不只是“模型调用了工具”，而是工具结果会影响下一轮控制流。
因此，AgentScope 中的 Agent 更适合理解为一个控制循环引擎：
text
Agent
=
Model
+ Context
+ Tool
+ Observation
+ Control Loop这也意味着，同一个模型被放入不同的 Agent Runtime，可能表现出完全不同的任务能力。
模型能力只是其中一个变量。
Agent 最终如何行动，还取决于：
text
Agent 行为
=
模型能力
× 上下文质量
× 行动空间
× 环境反馈
× 执行边界从这个角度看，Agent 不是一个模型，而是模型被放入某种环境以后形成的行为系统。
4. 行动空间
在传统应用中，API 是程序调用的接口。
在 Agentic 应用中，Tool 还有另一层含义：它是模型能够理解和选择的行动。
AgentScope 通过工具名称、描述和参数 Schema，把外部能力暴露给模型。模型不需要知道底层 Java 或 Python 代码如何实现，只需要理解：
- 这个工具能够做什么；
- 什么情况下应该使用；
- 需要提供哪些参数；
- 可能得到怎样的结果。
假设企业研究 Agent 拥有以下工具：
text
search_web
read_webpage
query_financial_statement
run_python
read_file
write_report从程序角度看，这只是六个接口。
从 Agent 角度看，这六个接口共同构成了它的行动空间。
它可以选择：
text
搜索公开资料也可以选择：
text
查询结构化财务数据还可以选择：
text
使用 Python 计算增长率和现金转换周期Agent 并不是任意行动，而是在开发者定义的有限动作集合中选择下一步。
因此，Tool 设计不是简单的接口封装。
一个工具至少需要回答几个问题：
- 它与其他工具的边界是什么？
- 什么情况下应该调用它？
- 参数语义是否足够明确？
- 是否会产生外部副作用？
- 调用失败后，Agent 能否理解失败原因？
- 返回结果是否足以支持下一轮决策？
- 结果过大时应该如何处理？
- 是否需要用户审批？
例如，下面的错误结果：
text
查询失败。几乎无法帮助 Agent 自主恢复。
更有效的反馈应该是：
text
查询失败：字段 revenue 不存在。
当前数据源支持以下字段：
- operating_revenue
- net_profit
- operating_cash_flow
- report_date
请修改字段后重新查询。在普通程序中，这是一段异常信息。
在 Agentic 系统中，它还是模型对环境的一次观察。观察越清楚，Agent 越有可能在下一轮修正行动。
因此，工具返回值不仅是函数结果，也在参与控制流。
可以把 Tool 看成 Agent 使用的一门行动语言：
- Tool 名称是动作；
- Tool 描述是语义；
- 参数 Schema 是语法；
- Tool Result 是环境反馈。
工具太少，Agent 无法完成任务。
工具太多、描述重叠，模型又容易误选。
因此，复杂 Agent 往往还需要根据任务阶段动态调整工具集合。
企业研究 Agent 在任务开始时可能只需要搜索和阅读工具；进入数据分析阶段后，再开放财务查询和 Python；进入结果生成阶段后，再开放文件写入能力。
这不是简单的工具管理，而是在动态收缩或扩展模型当前的行动空间。
5. 状态管理
如果 Tool 决定 Agent 能做什么，那么 Context 决定 Agent 认为当前发生了什么。
很多早期 Agent 实现会把 Context 简化为聊天记录：
text
User: 请分析这家公司
Assistant: 好的
User: 继续
Assistant: ……但对于真正的 Agent 任务，这还远远不够。
Agent 的工作上下文通常还包括：
- 用户目标；
- 系统约束；
- 已经调用过的工具；
- 工具返回的结果；
- 当前计划；
- 尚未解决的问题；
- 已经生成的中间产物；
- 用户已经确认或拒绝的操作。
例如，模型当前看到的状态可能是：
text
任务：
分析某企业最近半年的经营风险。
已经知道：
- 营业收入增长 15%
- 净利润增长 3%
- 经营现金流下降 40%
- 应收账款上升 55%
已经执行：
- 查询最近两个季度财务数据
- 搜索行业新闻
- 尚未阅读财报附注在这样的上下文下，模型下一步很可能会：
- 阅读财报附注；
- 调查应收账款变化；
- 计算现金转换周期；
- 查询收入增长是否来自信用销售。
如果工具结果没有被正确保存，Agent 就可能重复搜索，或者基于不完整信息做出判断。
因此，Context 并不是附属的消息列表，而是 Agent 当前用于决策的工作状态。
但 Context 也不能无限增长。
一次开放任务可能包含数十次模型调用、网页全文、代码输出和文件内容。如果全部原样送入模型，不仅成本会持续增加，真正重要的信息也可能被噪声淹没。
因此，Agent Runtime 需要持续维护有效上下文，例如：
- 对较早的消息进行结构化摘要；
- 保留最近几轮的原始内容；
- 对超大工具结果进行截断；
- 将长内容写入文件，只在上下文中保留摘要和引用；
- 把关键结论、未完成事项和错误原因保留下来。
这意味着 Agent 的状态管理并不是“保存得越多越好”。
更合理的目标是：
维护一份足以支持下一步决策的有效状态。
它既不能丢失关键事实，也不能让历史噪声无限堆积。
这是一种认知状态管理，而不仅是聊天记录持久化。
6. 消息与事件
普通聊天应用通常只关心最终回复。
但一个 Agent 任务可能持续几分钟，期间调用多个工具、等待外部系统、请求用户确认，甚至启动其他 Agent。
如果框架只在任务结束后返回一段文本，整个执行过程就会成为黑盒。
AgentScope 因此区分了两类数据：
- Message 表示一次完整的语义结果；
- Event 表示执行过程中不断发生的增量事件。
一次 Agent 调用可能产生如下事件：
text
ReplyStart
ModelCallStart
ThinkingBlockDelta
ToolCallStart
ToolCallResult
ModelCallStart
TextBlockDelta
ReplyEnd这些 Event 可以实时告诉上层应用：
- Agent 是否已经开始执行；
- 当前是否正在调用模型；
- 当前正在调用什么工具；
- 工具是否成功；
- 是否需要用户审批；
- 最终文本已经生成到什么位置。
当整个调用结束后，这些过程信息可以收敛为一个完整的 Message。
例如，最终 Message 可能只是：
text
该企业当前最值得关注的风险是经营现金流恶化，
其收入增长可能部分依赖信用销售扩张……但在形成这个结论之前，Agent 可能经历：
text
查询财务数据
→ 发现现金流异常
→ 阅读财报附注
→ 计算应收账款周转
→ 查询同行数据
→ 交叉验证
→ 生成结论Message 与 Event 的分离，本质上是在区分：
text
任务最终产生了什么和：
text
任务是如何运行的这个区分不只是为了实现流式输出。
它让 Agent 的动态执行过程具备：
- 可观察性；
- 可中断性；
- 可审批性；
- 可回放性；
- 可追踪性；
- 可统计性。
在 Workflow 中，可观测性的核心通常是：
text
当前运行到了哪个节点？在 Agentic 系统中，还需要回答：
text
Agent 为什么选择这个行动？
这个行动得到了什么反馈？
这个反馈如何影响了后续行动？这也是 Agentic 应用调试方式发生变化的地方。
开发者不再只检查流程节点，还需要检查整条任务轨迹。
7. 执行约束
把路径选择权交给模型，很容易被理解为“让模型自主完成一切”。
但真正可用的 Agentic 系统并不是无限自治，而是有边界的运行时自治。
当模型只能生成文本时，错误通常停留在内容层。
当 Agent 可以执行真实动作时，风险会迅速扩大：
- 修改文件；
- 执行 Shell 命令；
- 访问数据库；
- 发送邮件；
- 创建工单；
- 调用采购系统；
- 操作线上环境。
因此，AgentScope 需要在工具执行前加入权限判断。
一个工具调用可以得到三类决策：
text
ALLOW
DENY
ASK例如：
text
读取工作区内的报告
→ ALLOW
覆盖已有报告文件
→ ASK
访问未经授权的客户数据库
→ DENY这里体现了 Agentic 与 Workflow 不同的控制方式。
Workflow 主要通过规定路径进行控制：
text
只能先执行 A，再执行 B，最后执行 C。Agentic 则更多通过规定行动边界进行控制：
text
可以自行选择执行路径，
但只能使用指定工具，
只能访问指定资源，
只能消耗指定预算，
危险操作必须确认。控制没有消失。
它只是从“规定每一步”转移到了：
- 权限范围；
- 数据边界；
- 资源预算；
- 审批节点；
- 停止条件；
- 结果验收。
因此，“从编排流程到定义目标”绝不意味着开发者只需要写一句 Prompt。
一个可执行的目标，至少应该包含：
text
要完成什么
完成到什么程度
可以使用什么能力
不能触碰什么边界
如何判断结果可信
什么情况下必须停止这更像一份任务契约，而不是一句自然语言愿望。
Agentic 开发并没有取消控制，而是在重新设计控制。
8. Harness
一个基础的 ReAct 循环，可以解决这样的问题：
收到一次请求后，模型如何通过若干次推理和工具调用完成任务？
但真实 Agent 还需要面对更多长期问题：
- 下一轮请求如何接着上一轮继续？
- 上下文不断增长怎么办？
- 不同用户的文件如何隔离？
- 危险命令应该在哪里执行？
- 任务经验如何沉淀？
- 什么时候应该调用子 Agent？
- 服务重启以后如何恢复？
这也是 AgentScope 中 Harness 这一层存在的意义。
可以把 AgentScope 的结构理解为：
text
┌──────────────────────────────┐
│ Agent Core │
│ │
│ Reasoning → Acting → Observe │
│ │
│ Model / Tool / Context │
└──────────────┬───────────────┘
│
┌──────────────▼───────────────┐
│ Harness │
│ │
│ Workspace / Memory │
│ Compaction / Sandbox │
│ Skill / Subagent / Plan │
└──────────────────────────────┘Agent Core 负责：
text
根据当前状态选择下一步行动Harness 负责：
text
让这个行动循环可以长期、安全、连续地运行这是一种重要的架构分层。
Workspace
Workspace 不只是临时目录。
它可以同时承载：
- Agent 的身份定义；
- 领域知识；
- 可用工具配置；
- Skill；
- 子 Agent 定义；
- 当前计划；
- 长期记忆；
- 任务生成的文件。
例如：
text
workspace/
├── AGENTS.md
├── tools.json
├── MEMORY.md
├── knowledge/
│ └── industry.md
├── skills/
│ └── competitor-analysis/
│ ├── SKILL.md
│ └── references/
├── subagents/
│ └── financial-analyst.md
└── plans/
└── PLAN.md这使 Agent 的一部分能力不再完全固化在代码中，也可以通过普通文件进行维护、审阅和版本管理。
Memory
Memory 关注的是：
text
跨任务以后，哪些事实值得继续保留？例如：
- 用户长期偏好；
- 企业术语；
- 已经确认的业务规则；
- 有价值的任务经验；
- 需要长期记住的领域知识。
Compaction
Compaction 关注的是另一个问题：
text
当前任务的上下文太长了怎么办？它会压缩早期过程、保留近期信息，并把超大内容卸载到外部存储。
因此：
text
Memory
= 跨任务保留什么
Compaction
= 当前任务如何装得下Skill
Tool 描述的是一个原子动作：
text
查询数据库
读取文件
执行脚本Skill 描述的是完成一类任务的方法：
text
如何分析财务报表
如何完成竞争对手分析
如何验证信息来源可以概括为：
text
Tool 解决“能做什么”
Skill 解决“应该怎样做”Skill 可以包含说明文档、参考资料、脚本和案例，并在需要时由 Agent 按需加载。
Plan
计划模式允许 Agent 先进行只读分析：
text
理解目标
↓
收集信息
↓
形成计划
↓
用户确认
↓
进入执行但这里的 Plan 与 Workflow 仍然不同。
Workflow 的计划是开发者事先编译好的节点和边。
Agent 的计划则是模型面对具体任务和实际环境以后，动态生成的一份执行意图。
计划可以保存，也可以根据新的环境反馈继续调整。
Sandbox
当 Agent 可以执行代码、安装依赖和生成文件时，仅靠 Prompt 约束并不可靠。
Sandbox 将这些行动限制在隔离环境中，并控制：
- 文件系统范围；
- 网络访问；
- CPU 与内存；
- 执行时长；
- 依赖安装；
- 用户与 Session 隔离。
这再次说明，生产级 Agent 需要的不只是一个模型 SDK，而是一套完整的运行环境。
9. 运行时委派
AgentScope 以多 Agent 能力受到关注，但多 Agent 经常被简单理解成多个角色互相对话：
text
研究员 Agent
评论员 Agent
经理 Agent
主持人 Agent这类角色模拟有时有效，但多 Agent 更实际的价值通常来自三个方面。
上下文隔离
财务分析只需要财务数据和财务工具。
法律分析只需要法律资料和法律工具。
如果所有信息、工具和任务都堆在一个 Agent 的上下文中，模型反而更容易受到噪声干扰。
能力隔离
不同 Agent 可以使用不同模型和工具。
例如：
text
financial-analyst
→ 财务数据库、Python、财报文件
industry-analyst
→ 搜索、网页阅读、行业数据库
writer
→ 报告模板、文件写入权限隔离
不同 Agent 还可以拥有不同权限。
某个 Agent 只能读取公开信息，另一个 Agent 可以访问内部数据，但不能修改系统。
多 Agent 因而不仅是任务分工，也是安全边界。
Agentic 视角下更值得关注的是：委派关系是否必须提前写死。
在固定多 Agent Workflow 中，结构可能是：
text
研究 Agent
↓
财务 Agent
↓
审核 Agent而在运行时委派中，主 Agent 可以根据任务进展临时判断：
text
当前发现财务异常
→ 启动 financial-analyst
当前没有明显法律风险
→ 不启动 legal-analyst如果研究过程中突然发现企业的主要问题来自海外监管，主 Agent还可以临时调用政策分析 Agent。
这体现了更深一层的 Agentic 思想：
不仅任务路径可以动态形成，任务分工结构也可以在运行时形成。
当然，并不是所有协作结构都应该动态生成。
如果组织关系和审核顺序本来就是确定的，例如：
text
初审
→ 合规复核
→ 人工审批那么显式 Graph 通常更合适。
关键仍然是：这段结构在设计阶段是否已经确定。
10. Agent-first 与 Graph-first
不能简单地把 AgentScope 和 Spring AI Alibaba 描述成：
text
AgentScope = Agent
Spring AI Alibaba = WorkflowSpring AI Alibaba 同样具备 Agent、ReAct、工具、多智能体和 Human-in-the-Loop 等能力。
真正值得比较的，是两种默认的建模视角：
text
Agent-first
vs.
Graph-firstGraph-first
开发者首先思考：
- 任务可以拆成哪些节点？
- 节点之间如何连接？
- 共享状态包含哪些字段？
- 什么条件下走哪条边？
- 在哪里设置检查点？
- 失败后从哪个节点恢复？
其核心结构是：
text
State
+ Node
+ Edge
+ GraphAgent-first
开发者首先思考：
- Agent 要完成什么目标？
- 它可以观察到什么？
- 它可以采取哪些行动？
- 工具应该提供怎样的反馈？
- 哪些动作需要禁止或审批？
- 如何判断任务已经完成？
其核心结构是：
text
Goal
+ Context
+ Tool
+ Environment
+ Constraint两种范式可以概括为：
Graph-first 是确定性的控制器，内部包含概率性的模型节点。
Agent-first 是概率性的控制器，外部包裹确定性的工程边界。
| 维度 | Agent-first | Graph-first |
|---|---|---|
| 核心抽象 | Agent、Context、Tool、Environment | State、Node、Edge、Graph |
| 下一步由谁决定 | 模型根据当前观察选择行动 | 开发者定义边和状态转换 |
| 主要描述对象 | 目标、能力、反馈、边界 | 步骤、分支、状态、顺序 |
| 路径形成时间 | 运行时动态形成 | 设计时显式定义 |
| 状态关注点 | Agent 当前知道什么、做过什么 | 流程当前运行到了哪里 |
| 错误处理 | 把错误作为观察重新决策 | 重试节点、切换分支、恢复检查点 |
| 测试重点 | 目标完成度与任务轨迹 | 节点结果与状态转换 |
| 主要优势 | 适应未知情况 | 可预测、可审计、可复现 |
| 主要风险 | 循环、漫游、工具误用、成本波动 | 分支膨胀、路径僵化、覆盖不足 |
这里没有先进与落后之分。
它们解决的是两种不同的问题。
Workflow 适合已经知道如何完成的任务。
Agentic 适合只有目标明确，但具体路径需要在执行过程中探索的任务。
11. 分层控制
真实企业应用通常既不适合完全交给 Agent，也不适合把所有情况都写成固定 Workflow。
更合理的方式是：
text
Workflow 管理确定性
Agent 处理不确定性仍然以企业研究系统为例：
text
Graph：身份认证
↓
Graph：确定数据访问范围
↓
Graph：创建研究任务
↓
AgentScope：完成开放式调研
├── 动态搜索
├── 阅读资料
├── 调用代码
├── 调整计划
└── 委派子任务
↓
Graph：校验报告结构
↓
Graph：检查证据完整性
↓
Graph：合规审核
↓
人工审批
↓
Graph：发布报告在这个系统中：
- 身份认证是确定的；
- 数据访问范围是确定的；
- 审批流程是确定的；
- 报告发布动作是确定的；
- 调研过程是不确定的。
因此，外围使用 Graph，内部使用 Agent。
也可以反过来，让 Agent 把固定 Workflow 当成一种能力：
text
用户：
“帮我完成下周去杭州的客户拜访安排。”
Agent：
1. 理解用户目标；
2. 查询日历、天气、航班和酒店；
3. 形成出行方案；
4. 调用企业差旅申请 Workflow；
5. 根据审批结果继续调整。Agent 负责理解目标、收集信息和选择能力。
Workflow 负责稳定执行企业已经定义好的流程。
这种混合架构的关键，不是简单地把两个框架放在一起，而是明确控制权的分层：
text
业务治理层
→ Graph 控制
开放任务层
→ Agent 控制
原子执行层
→ Tool 控制
高风险动作
→ Permission 与 Human-in-the-Loop 控制不同层次使用不同的控制方式。
确定性越高，越适合显式流程。
不确定性越高，越适合运行时决策。
风险越高，越需要在 Agent 外部增加权限、审批和验证。
12. 结语
Workflow 时代，开发者主要设计：
text
步骤
顺序
分支
状态转换
异常路径Agentic 时代，开发者开始更多地设计：
text
目标
行动空间
工作上下文
环境反馈
权限边界
停止条件
评估标准这并不意味着代码变少了，也不意味着 Prompt 取代了程序。
变化在于，程序的一部分从显式流程变成了运行时决策环境。
AgentScope 把这种变化具体化了：
- ReAct 循环负责持续推理与行动；
- Tool 构成模型的行动空间；
- Context 保存当前工作状态；
- Message 表达完整语义；
- Event 暴露实时执行过程；
- Permission 限制行动边界；
- Harness 提供长期运行条件；
- Subagent 支持运行时任务委派。
因此，AgentScope 背后的 Agentic 范式并不是简单地告诉开发者：
不要再画流程图了。
它真正提出的问题是：
当任务路径无法提前确定时，我们能否不再穷举所有步骤，而是为模型定义目标、提供能力、建立反馈，并设置可信边界？
Workflow 解决的是：
text
如何可靠地重复一条已知路径。Agentic 解决的是：
text
如何在路径未知时，根据环境反馈持续接近目标。真正成熟的 AI 应用，需要知道什么时候应该定义路径，什么时候应该只定义目的地。