Agentic 系统

我越来越觉得，“要不要上 agent”这个问题经常被问错了。真正该问的不是它高级不高级，而是你的任务到底需要把多少控制权真的交给模型。

核心区分

building-effective-ai-agents 给出的关键区分不是“有没有工具”，而是谁在掌控流程。这点很关键，因为很多看起来很像 agent 的系统，其实只是套了一层模型的 workflow。

Workflow：执行路径由开发者预定义，模型在框架内完成局部子任务。
Agent：模型根据当前上下文与环境反馈，动态决定下一步做什么。

因此，workflow 更像“带 LLM 的程序编排”，agent 更像“带工具与反馈回路的模型驱动执行体”。

复杂度阶梯

从低复杂度到高复杂度，可以把 agentic systems 看成一条连续谱：

增强型 LLM：单轮调用 + 检索 / 工具 / 记忆。
Prompt chaining：串行拆解，降低每步难度。
Routing：按类别把输入分流给不同处理路径。
Parallelization：并行处理子任务或多次投票。
Orchestrator-workers：动态分配子任务，再汇总。
Evaluator-optimizer：生成、评估、重试形成闭环。
Autonomous agent：在环境中多轮行动，持续自我校正。

这条阶梯的价值不在于“越往后越高级”，而在于提醒自己：优先选择能满足目标的最低复杂度方案。 我很喜欢这种工程判断，因为它天然反对“为了追求 agent 而 agent”。

实时协作：一个新的维度

interaction-models 提出了一个不完全落在上述阶梯上、但同样重要的分类：agent 是否需要与人类在实时时间流中共处。传统的 turn-based 模型无论多智能，都在等待-生成-等待的循环中运行；而 interaction model 以 200ms micro-turns 持续感知和响应，把协作从”回合制”变成”流式”。

这个范式变化的关键在于，它引入了一种新的系统分工：

Interaction model：负责实时 presence，保持低延迟的双向多模态交互
Background model：负责深度推理和工具调用，异步返回结果

两者不是简单的”快模型”和”慢模型”的关系，而是同一智能体在不同时间尺度上的两个面相。Interaction model 决定”什么时候说”，background model 决定”说什么最有深度”。这与 multi-agent-systems 中的 orchestrator-worker 模式有相似之处，但分工逻辑不同——不是按任务并行度拆分，而是按实时性需求拆分。

我觉得这个维度未来可能会成为 agentic system 设计中的独立考量：你的应用场景需要回合制交互，还是流式协作？这个选择会影响从模型架构到推理系统到安全策略的整套设计。

how-we-built-our-multi-agent-research-system 则补上了一个关键现实：当任务天然适合 breadth-first 并行探索时，orchestrator-worker 型多智能体可以被看作这条阶梯上“并行化 + 长程自治”的一次组合升级。它不是默认终点，而是只在研究类任务中非常有效的一种特化形态。

什么时候用 workflow

适合 workflow 的任务通常有几个特征。它们共同指向一件事：你其实已经足够理解问题结构，没必要为了灵活性支付过高的不确定性成本。

子任务结构相对清晰；
可以预先写出主要路径；
希望更强的可预测性与一致性；
可以接受较低的灵活性，换取更好调试性。

这时，把任务拆成链式、路由式或并行式结构，往往比直接放权给自治 agent 更可靠。

什么时候用 agent

适合真正 agent 的任务通常满足：

所需步骤数难以提前确定；
每一步是否继续，取决于环境反馈；
任务允许模型持续做局部决策；
有外部“ground truth”可帮助纠错，例如工具返回值、代码执行结果、自动化测试。

最典型例子是 coding agent：它可以修改代码、运行测试、再根据失败结果继续迭代。这里的关键不是“它能循环”，而是环境会不断给它返回新的、可检验的事实。

风险与约束

agent 的优势来自自治，但风险也来自自治。我现在会把这部分看成 agent 真正的成本表，而不是附录里的注意事项：

成本更高；
错误会在多轮循环中累积；
不透明的中间推理让调试更难；
如果缺少停止条件与人工检查点，容易失控。

进一步看，scaling-managed-agents-decoupling-the-brain-from-the-hands 说明真正成熟的 agentic system 还需要区分：

会话层：保存可恢复、可回放的历史；
harness 层：管理上下文、调用模型、连接工具；
执行层：真正做动作的 sandbox 或外部工具。

也就是说，agentic system 不只是 prompt + tools，还包含一套运行时架构。

oh-my-openagent 则把这种运行时架构做得非常具体：它不是抽象地讨论”harness 层应该做什么”，而是实现了 10 个 hook handler、53 个 lifecycle hook、26 个工具和 11 个 agent，把 orchestrator-worker 模式落地为一个可安装的 OpenCode 插件。omo 让我看到，agentic system 的复杂度阶梯不是理论概念，而是可以逐层实现的基础设施：从简单的 prompt chaining，到 category 路由，到后台并行，到模型回退，到生命周期管理，每一层都有对应的代码模块。

omo 的 Sisyphus 尤其值得注意：它被显式训练为”默认委派”（default bias: DELEGATE），只在任务 trivial 时才自己处理。这与很多人直觉上的”agent 应该尽量自治”相反——omo 认为，更好的自治是知道什么时候不该自治，而是把任务交给更适合的 specialist。

因此，agent 设计通常需要配套：sandbox、guardrails、迭代上限、人工介入点与显式日志。

一个实用判断句

如果你很难解释“为什么一定需要多轮自治，而不是更好的单轮 prompt / 检索 / workflow”，那通常说明现在还不需要 agent。

来源：building-effective-ai-agents · how-we-built-our-multi-agent-research-system · scaling-managed-agents-decoupling-the-brain-from-the-hands · interaction-models · oh-my-openagent

kaikai's wiki

探索