今天刷到了一篇Anthropic2024年的一篇文章，叫《Building effective agents》，文章的核心观点是:构建成功的AI Agent系统的关键在于使用简单、可组合的模式，而非依赖复杂的框架。
根据Anthropic的这篇文章，Agent系统被分为两大类：工作流（Workflows） vs. 自主Agent（Agents）。其定义如下：
工作流（Workflows）：通过预定义的代码路径编排LLM和工具，适用于任务定义明确、需要高度预测性和一致性的场景。
自主Agent（Agents）：LLM可以动态地指导自己的流程和工具使用，对如何完成任务保持控制权。 这适用于无法预定义路径、需要模型根据环境反馈进行推理和规划的开放式问题。
继Openclaw爆火之后，Agent的架构编排也是一个比较热门的话题，像LangGraph的状态机模型、AutoGen的多角色对话、CrewAI的角色驱动任务委派都是当前主流选择。此外还有Agent内部的控制流、上下文工程、工具设计、记忆、多 Agent 组织、Harness等等。哪个部分才是重点？
解决方案的价值在于问题被解决。
试想一下，如果现在你想削苹果，但是没有削皮刀，你会怎么做？是会用嘴把皮啃完吐掉，还是去买个削皮刀再回来继续吃？生活中，两种其实都有可能，但如果说，当你的需求与框架不相符，你实际在做的事可能是在手绘削皮刀模型->送厂打样->物流到家发现用不了->修改模型直到能用。这么做一遍，你的投入和收益真的还成正比吗，可能你这辈子都不想吃苹果了。
如何避免过度工程？
先说结论：构建系统时，应优先从最简单的解决方案（如单次LLM调用）开始。只有当简单的方案无法满足需求时，才考虑增加复杂度并引入上述架构模式。
在Anthropic的这篇文章中，讲述了5种常见的控制模式：
提示词链（Prompt Chaining）
核心概念：将一个复杂任务分解为一系列顺序步骤。每一个LLM调用的输出都会作为下一个LLM调用的输入。在中间步骤可以加入程序化的检查（即“门控”步骤），以确保流程不偏离轨道。
适用场景：当任务可以清晰地分解为固定子任务时最为理想。这种模式通过增加延迟来换取更高的准确性，因为每个LLM调用处理的任务都变得更简单、更聚焦。
典型案例：先生成营销文案，再将其翻译成另一种语言。先撰写文档大纲，检查大纲是否符合标准，最后根据大纲撰写全文。
路由（Routing）
核心概念：首先对输入进行分类，然后将其引导至专门的后续任务路径。这种模式实现了关注点分离，允许为不同类型的输入构建专门优化的提示词。
适用场景：适用于存在截然不同的任务类别，且分类准确率较高的复杂任务。如果没有路由，强行用一个提示词兼容所有情况，往往会顾此失彼。
典型案例：客服分流：将用户查询分类为普通咨询、退款请求或技术支持，分别引导至不同的下游流程和工具。模型路由：将简单、常见的问题路由给轻量化模型（如Claude Haiku），而将困难、罕见的问题交给高性能模型（如Claude Sonnet），从而平衡成本与性能。
并行化（Parallelization）
核心概念：让LLM同时处理任务，并由程序自动聚合输出结果。它有两种主要变体：分段（Sectioning）：将任务拆分为独立的子任务并行运行。投票（Voting）：多次运行同一个任务以获取多样化的输出。
适用场景：需要通过并行化提高处理速度，或者需要多个视角/多次尝试来获得更高置信度的结果时非常有效。
典型案例：分段示例：在处理用户查询时，一个模型实例负责响应，另一个模型实例并行地进行内容安全审查。投票示例：进行代码漏洞审查时，使用多个不同的提示词对同一段代码进行审查，如果有任何一个提示词标记了风险则触发预警。
协调者-执行者（Orchestrator-Workers）
核心概念：由一个中心LLM（协调者）动态地分解任务，分配给多个执行者LLM（Worker），最后综合处理它们的结果。与并行化的区别：并行化的子任务通常是预定义的，而该模式的子任务是协调者根据具体输入动态决定的，灵活性更高。
适用场景：适用于无法预知具体需要哪些子任务的复杂任务。例如在编程任务中，需要修改哪些文件、如何修改，完全取决于具体的任务描述。
典型案例：复杂代码修改：需要跨多个文件进行协同更改的代码产品。复杂搜索任务：需要从多个来源搜集、分析并整合信息的任务。
评估者-优化者（Evaluator-Optimizer）
核心概念：一个LLM负责生成响应，另一个LLM负责评估该响应并提供反馈，形成一个循环迭代的过程。
适用场景：当任务有明确的评估标准，且迭代精炼能带来可衡量的价值提升时最为有效。这种模式类似于人类作家的迭代写作过程。
典型案例：文学翻译：翻译模型初步翻译后，由评估模型针对细微差异和文学性提出批评，再由翻译模型进行优化。多轮搜索：评估者判断当前的搜索结果是否全面，如果不全面则决定进行下一轮更深入的搜索和分析。
选择一个合适的架构有什么好处？
根据Anthropic的这篇文章以及《Effective context engineering for AI agents》得出的结论有以下几点：
1. 显著提升透明度与易调试性：复杂的框架往往会创建多层抽象层，这会掩盖底层的提示词（prompts）和模型响应，使开发者难以追踪 Agent 的具体行为。采用简单模式可以让开发者直接通过 API 观察每一步的交互，从而更轻松地进行故障排查和优化。
2. 增强系统的可靠性与可维护性：在 Agent 系统中，微小的错误往往会随流程级联放大。硬编码的复杂逻辑或重度框架依赖会增加系统的脆弱性（Fragility）稳定、健壮。
3. 避免过度复杂化（Over-engineering）：框架有时会诱导开发者在简单的 setup 就能解决问题时增加不必要的复杂度。通过简单模式，开发者可以遵循**“从简单开始”的原则，仅在评估证明更复杂的架构（如多步循环）能显著提升任务性能时，才引入额外复杂度。
4. 建立用户信任：简单的设计通常更具透明度，能够向用户清晰地展示 Agent 的规划和执行步骤。当系统的运作逻辑对用户可见且可预测时，更容易获得用户的长期信任。
5. 提供更好的控制力与针对性优化：依赖底层 API 编写简洁的代码（通常只需几行），可以让开发者完全掌控“引擎盖下”的逻辑，避免因对框架机制产生错误假设而导致失误。同时，这方便开发者将精力集中在设计高质量的Agent-计算机接口（ACI，Agent-Computer interface）和工具文档上，这往往比优化系统架构更能提升性能。
总之，Agent开发的关键不在于构建最尖端的系统，而在于构建最适合需求（Right System）的系统，设计上的简洁能够使得Agent系统更加简洁可靠。
