【手搓 Agent 第0关】认知扫盲篇（下）：Agent 工程选型、架构体系、场景落地完整论证

上一篇，我们了解了 Agent 基本概念和循环，本篇，我们将结合 Anthropic: Building effective agents 和 OpenAI: A practical guide to building agents，聚焦工程落地实战，详解 Agent 选型原则、官方架构体系、五大经典工作流、安全护栏机制。

一、智能体工程选型核心原则：优先最简方案，按需增复杂度

Agent 不是万能方案，反而会带来延迟提升、使用成本增加、模型幻觉不确定性等问题。工程开发第一准则：能简单绝不复杂，坚决拒绝过度工程。

1.1 严格选型标准

1. 常规简单场景：仅通过单轮 LLM 调用、检索+提示词优化即可解决，无需搭建工作流与智能体。

2. 流程固定、规则明确场景：优先选择 Workflow，优势是结果可预测、稳定性强、零不确定性。

3. 场景开放、需要柔性决策场景：必须选择 Agent，依靠其动态决策能力适配复杂、不确定的业务场景。

1.2 Agent 专属适配场景

• 复杂决策类：依赖细致人工判断、存在大量异常分支、需要上下文关联决策（例：客服智能退款审批、客户意图研判）。

• 规则难维护类：业务规则体系庞大冗余、迭代更新频繁、硬编码成本高且极易出错（例：供应商安全审查、动态合规校验）。

• 非结构化数据类：需要解析自然语言、读取解析各类文档、多轮对话交互推理（例：房屋保险理赔、企业文档智能分析）。

1.3 框架选型优劣势与官方实操建议

目前主流 Agent 开发框架包含 LangGraph、Amazon Bedrock AI Agent 框架、Rivet、Vellum 等，各有适配场景。

框架优劣势：

• 优势：封装 LLM 调用、工具解析、链式调用等底层逻辑，上手速度快，快速落地原型。

• 劣势：多层抽象封装，遮挡提示词与返回原始结果，调试难度大幅提升；易诱导开发者过度设计，引入不必要的系统复杂度。

官方最优实操建议：

1. 入门阶段优先直接调用 LLM 原生 API，绝大多数基础模式仅需少量代码即可实现，吃透底层原理。

2. 业务迭代需要提效时，再引入框架；使用框架必须吃透底层源码与运行机制，避免认知偏差引发线上故障。

二、整体技术架构：从基础模块到完整智能体系统

所有 Agent 系统均遵循统一演进路径：增强型 LLM（底层基础） → 组合式工作流 → 自主智能体，层层递进，逐步提升智能化与自主性。

2.1 基础构建模块：增强型 LLM（Augmented LLM）

增强型 LLM 是所有智能体系统的底层核心，在原生 LLM 文本生成能力基础上，叠加三类核心能力：检索、工具、记忆，让模型从「只会说话」变成「能做事、能记事、能查资料」。

核心落地要点：

• 结合自身业务场景定制增强功能，不堆砌无用能力；

• 为 LLM 配置简洁、完善、标准化的调用接口，降低适配成本；

• 可借助 MCP（模型上下文协议）快速对接第三方工具生态，拓展能力边界。

2.2 五大经典工作流（Workflows）

复杂自主 Agent 均由基础工作流组合迭代而来，是开发必备前置知识，适配绝大多数企业自动化场景：

（1）提示链 Prompt Chaining

将复杂任务拆分为固定串行步骤，每一步 LLM 处理上一步输出结果，可增设程序校验节点保障准确率。

适用场景：任务可清晰拆解为固定子步骤，愿意牺牲部分延迟，换取更高输出质量。

典型案例：营销文案撰写+多语言翻译、文档大纲审核+正文精细化撰写。

（2）路由 Routing

先对用户输入、任务类型做分类，再分发至专属流程、提示词或工具，实现「关注点分离」，精准适配差异化需求。

适用场景：任务类型多样，不同类别需要差异化处理，分类逻辑可精准执行。

典型案例：客服咨询分流（通用问题/退款申诉/技术支持）、按问题难度分配不同规格模型，平衡速度与成本。

（3）并行化 Parallelization

将多个独立子任务同步执行，分为分段并行与投票并行两种形态，大幅提升处理效率与结果准确率。

• 分段并行：拆分独立子任务同步运行，适用于多模块互不依赖、需要提速的场景（案例：内容合规筛查+常规应答同步执行）。

• 投票并行：同一任务多次运行，汇总多份输出交叉校验，降低出错概率（案例：代码漏洞审查、内容违规判定）。

（4）协调器 - 工作者 Orchestrator-Workers

由中央协调器 LLM 动态拆解复杂任务，实时生成子任务并分配给多个工作者 LLM 执行，最终汇总整合结果。子任务无需预先定义，灵活性远超普通并行工作流。

适用场景：超复杂任务，无法提前预判子任务数量与执行逻辑。

典型案例：多文件批量代码修改、多源信息搜集与整合分析。

（5）评估器 - 优化器 Evaluator-Optimizer

双 LLM 循环协作模式：优化器负责生成初始内容，评估器输出专业反馈，双向迭代打磨结果，持续优化输出质量。

适用场景：有明确评估标准，迭代优化可显著提升内容质量，模型可理解并产出有效反馈。

典型案例：专业文学翻译精修、多轮深度搜索分析与总结。

2.3 高阶形态：自主智能体 Agents

自主智能体是体系最终形态，需要 LLM 具备四大核心能力：复杂输入理解、自主推理规划、可靠工具调用、错误自主恢复。

完整运行逻辑：

1. 启动：接收用户指令与对话上下文，明确核心任务目标；
2. 执行：自主规划执行步骤、动态调用工具，依据工具返回的真实数据判断任务进度；
3. 交互：遇到卡点、异常或高风险操作，可暂停执行，请求人工辅助决策；
4. 终止：任务完成自动结束，可配置最大迭代次数等阈值，管控运行风险。

核心实现要点：Agent 本质是「LLM 在循环中结合环境反馈调用工具」，工具集设计+配套文档完善度是项目成败的核心关键。

落地适配与风险：仅适用于开放式、无法硬编码固定流程的问题，推荐在可信业务环境部署；缺点是运行成本更高、易出现错误累积，必须在沙箱充分测试，配置完善的防护机制。

典型落地案例：智能客服（对接客户数据、工单系统、知识库，自动处理咨询与工单更新）、编码智能体（自主修复代码问题，配套自动化测试校验，关键操作保留人工审核）。

三、智能体三大核心组件

3.1 LLM 模型选型策略

模型选型核心权衡维度：任务复杂度、响应延迟、调用成本，遵循「先基线、后优化」的工程准则：

1. 原型阶段：使用能力最强的模型搭建项目，建立性能基线，不提前限制模型能力；
2. 优化阶段：逐步替换轻量小模型，验证效果是否满足业务标准；
3. 落地阶段：在精度达标的前提下，优先选用小模型降低延迟与调用成本。

进阶方案：支持多模型混用，简单任务（意图分类、信息检索）用轻量模型控成本，复杂决策（风险审核、内容创作）用高阶模型保准确率。

3.2 工具设计规范与分类

工具是 Agent 的执行手脚，可拓展模型能力，对接各类外部 API、业务系统；针对无 API 的遗留系统，可通过计算机使用模型模拟人工 UI 操作完成交互。

工具设计通用标准：标准化定义、文档完善、高可复用、无功能冗余，便于版本管理与快速迭代。

智能体三大工具分类：

工具类型	核心作用	典型示例
数据类	检索业务上下文、获取原始数据与信息，为决策提供依据	查询 CRM/业务数据库、读取 PDF 文档、全网/内网搜索
操作类	执行业务动作，修改系统数据、完成闭环操作	发送消息、更新工单数据、发起退款流程
编排类	实现智能体之间互相调用，支撑多智能体架构协作	翻译智能体、检索智能体、写作智能体专项调用

扩容建议：若工具数量过多、功能重叠严重，优化工具文档与命名仍无法改善模型调用失误时，建议拆分多个专业智能体，简化系统复杂度。

3.3 指令编写最佳实践

指令直接决定智能体的行为边界与决策准确率，是 Agent 开发的核心核心环节，四大编写原则如下：

1. 复用现有资料：基于企业已有操作流程、知识库、政策文档、业务规范改写，贴合真实业务逻辑；
2. 拆解复杂任务：将冗长复杂流程拆分为清晰、简短的小步骤，减少语义歧义，降低模型理解成本；
3. 动作明确化：每条指令对应具体行为与输出结果，统一对外话术与操作标准，减少自由发挥带来的误差；
4. 覆盖边缘场景：预判信息缺失、异常提问、流程中断等问题，设计分支处理逻辑，完善异常兜底。

提效技巧：可使用 o1、o3-mini 等高阶模型，自动将企业现有文档、规范转化为标准化智能体指令，大幅提升开发效率。

四、智能体编排体系

4.1 基础运行机制：循环逻辑与退出条件

所有智能体的核心本质都是循环运行模式：反复执行 LLM 推理与工具调用，持续迭代，直至触发退出条件，结束任务。

常见退出条件：

• 调用预设的「最终输出工具」，任务闭环；
• LLM 直接返回文本响应，无需后续工具调用；
• 程序报错、达到最大执行轮次，强制终止迭代。

4.2 单智能体系统（新手起步最优方案）

工程开发优先原则：先最大化单智能体能力，再考虑多智能体拆分。通过逐步叠加工具、优化指令的方式迭代开发，控制系统复杂度，降低维护、调试与评估难度。

优化技巧：采用变量化提示模板，一套基础提示词搭配动态业务变量适配多场景，无需重复编写提示词，大幅降低维护成本。

4.3 单智能体拆分至多智能体的判断标准

单智能体出现以下两类问题，直接拆分多智能体架构：

1. 逻辑臃肿：提示词包含大量 if-else 分支、多层嵌套逻辑，流程复杂，无法迭代扩展；

2. 工具过载：工具数量多、功能重叠，即便优化工具命名、参数、描述，模型仍频繁选错工具、执行失误。

4.4 多智能体两大主流编排模式

模式 1：管理器模式（中央管控型）

架构组成：1 个中央管理器智能体 + 若干专业子智能体，所有子智能体被封装为管理器的专属工具。

运行逻辑：管理器统一接收用户请求、拆解任务、分配给对应子智能体、汇总整合结果，全程掌控流程，保证用户交互体验统一、规整。

适用场景：需要统一入口、标准化对外交互、整体把控流程的企业业务场景。

模式 2：去中心化移交模式（对等协作型）

架构组成：多个智能体地位对等，无中央管控，通过任务移交（Handoff）单向转移执行权。

运行逻辑：分诊/入口智能体识别任务类型，直接将流程移交给对应专业智能体全权执行，可按需配置移交回退能力。

适用场景：客服分诊、业务分流、专项问题独立处理等场景。

4.5 两种编排实现方式对比

• 声明式编排：提前用图结构（节点+边）定义所有分支、循环、条件，可视化效果强；但复杂流程配置繁琐，需要学习专属语法，灵活性差。

• 代码优先编排（OpenAI Agents SDK 采用）：基于常规代码实现动态流程，无需预定义全量图谱，适配动态多变的业务场景，灵活性、可拓展性更强。

五、智能体开发三大核心工程原则

1. 保持设计简洁：剔除所有冗余复杂度，保证系统架构清晰、代码易读、便于长期维护迭代；

2. 优先保证透明度：完整暴露模型的规划逻辑、决策过程、工具调用记录，提升业务可信度，便于问题排查；

3. 精心设计 ACI（智能体-计算机接口）：完善工具文档、全量覆盖测试，保障接口稳定、易用、低故障。

六、智能体安全护栏体系

护栏是智能体的多层风险防御机制，需要搭配身份鉴权、访问控制、常规软件安全机制协同使用，用于约束智能体行为，规避数据泄露、模型幻觉、恶意攻击、业务违规等各类风险。

6.1 七大护栏分类及核心作用

• 相关性分类器：拦截离题提问，严格限定智能体交互与执行范围，避免无效输出；
• 安全分类器：检测越狱攻击、提示注入、漏洞利用等恶意行为，防范模型被诱导违规；
• PII 过滤器：脱敏、拦截个人身份敏感信息，杜绝数据泄露风险；
• 内容审核：识别仇恨言论、暴力、骚扰等有害内容，保障交互环境合规安全；
• 工具风险管控：对工具划分低/中/高风险等级，高风险操作强制复核、人工兜底；
• 规则类防护：黑名单、输入长度限制、正则过滤、防注入等基础拦截能力，抵御已知风险；
• 输出验证：校验模型输出符合品牌规范、企业业务要求，避免违规、不当输出。

6.2 护栏落地原则

• 优先保障数据隐私与内容安全，筑牢基础防线；

• 基于线上真实故障、边缘场景持续迭代护栏规则，不盲目堆砌防护能力；

• 平衡安全强度与用户体验，随智能体迭代动态优化防护策略。

6.3 技术运行特点

主流 SDK 采用乐观执行机制：主智能体正常执行业务逻辑，护栏并行实时检测，一旦触发风险规则，立即抛出异常、终止流程，实现安全拦截。

标准防御链路：用户输入 → 规则防护 → 内容审核 API → LLM 安全分类器 → 相关性校验 → 正常执行 / 拦截报错。

七、人工干预兜底机制（生产环境必备）

人工干预是生产环境的核心兜底能力，在项目部署初期尤为重要，可帮助开发者发现模型缺陷、补齐边缘场景、持续迭代优化智能体能力，保障业务稳定不崩盘。

7.1 核心价值

当智能体无法完成任务、频繁执行失误、触发高风险操作时，优雅移交人工处理，规避业务事故，保障服务连续性。

7.2 两大强制触发场景

• 执行超限：智能体多次尝试仍无法识别用户意图、完成任务，达到重试次数、迭代轮次阈值，自动升级人工处理；

• 高风险操作：大额退款、订单注销、资金变动、数据删除等不可逆敏感操作，强制人工监督复核。

7.3 典型落地场景

客服复杂问题转接人工座席、代码智能体调试遇阻交还用户决策、高风险业务操作人工二次校验。

思考

读者可以尝试思考并简单回答以下问题：我的场景为什么需要 agent，而不是普通 workflow？来判断自己是否真的需要 agent。

本期总结和下期预告

手搓 Agent 第 0 关通过上下两篇，帮助我们完成从「基础认知」到「工程选型」的完整闭环：厘清核心概念差异、掌握智能体运行原理、吃透官方架构规范、学会工程取舍避坑，最终结合自身企业场景完成落地论证，明确了 Agent 的适用边界与核心价值。

下期 Stage1 预告：正式进入实操落地阶段，从零搭建最小可用 Agent，手写核心代码、打通完整 Observe-Think-Act 循环，搭建专属项目基础架构。