很多人以为 Agent 就是让模型自己调工具但这只是冰山一角。Agent 的核心不是自动化而是决策边界的管理。一个真正意义上的 Agent必须回答三个问题何时决策、如何决策、何时停止。如果这三个问题的答案完全由人工预设那不是 Agent是自动化脚本如果完全交给模型那不是 Agent是赌博。Agent 的本质Agent 是一个具备环境感知、自主决策、行动执行、反馈迭代能力的系统。它区别于传统软件的根本特征在于行为路径在运行时确定而非编码时固定。从工程角度看Agent 的本质是决策闭环观测 → 推理 → 行动 → 反馈 → 观测 → ...这个闭环有三个关键参数决策粒度每次行动前是否需要重新规划还是沿用既定策略反馈深度环境反馈是否改变内部状态还是仅作为下一个观测输入终止条件谁来定义任务完成是外部信号还是内部判断很多人把 Agent 理解为LLM 工具调用这忽略了最关键的状态管理和策略演化。一个成熟的 Agent 系统其复杂度不在工具层而在决策层如何让模型在不确定的环境中做出可预期的行为。五种主流 Agent 设计模式ReActReasoning ActingReAct 是最接近人类思维模式的 Agent 架构。其核心机制是思维-行动交替Thought: 我需要查询北京今天的天气 Action: search(北京天气 2026年8月1日) Observation: 北京今天晴气温28-35°C Thought: 用户问的是否适合户外活动我需要判断温度范围 Answer: 适合但需注意防暑适用场景任务可分解为明确步骤环境反馈相对确定性如 API 调用不需要长程规划单步决策即可推进局限无全局规划容易陷入局部最优依赖高质量 Observation环境噪声会放大决策失误Token 消耗随步数线性增长长任务成本高ReAct 的优势在于简单可控劣势在于无前瞻性。它适合走一步看一步的场景不适合需要全局协调的复杂任务。Plan-and-ExecutePlan-and-Execute 将决策拆分为两个阶段先规划再执行。Plan: 1. 收集用户需求文档 2. 分析技术栈选型 3. 生成架构设计方案 4. 输出详细技术文档 Execute: Step 1: 调用文件读取工具获取需求文档 Step 2: 调用知识库检索相关技术方案 ...适用场景任务有明确起点和终点步骤间依赖关系清晰执行环境相对稳定无需频繁调整计划局限计划阶段的质量决定上限一次规划失误会导致全盘失败执行阶段缺乏灵活调整能力环境变化时需要重新规划过度依赖初始信息新信息难以动态融入Plan-and-Execute 的本质是用确定性对抗不确定性。它假设环境足够稳定规划足够准确这在很多场景下是强假设。Multi-Agent多智能体协作Multi-Agent 将复杂任务拆解到多个 Agent每个 Agent 承担特定角色[ProductManager] 接收用户需求生成产品文档 [TechLead] 审查文档生成技术方案 [Developer] 实现方案输出代码 [Tester] 执行测试反馈问题适用场景任务复杂度超出单 Agent 决策能力需要跨领域知识协作有明确的角色分工和协作流程局限协调成本高Agent 间通信开销大角色边界模糊时会产生推诿或重复劳动整体稳定性取决于最弱环节Multi-Agent 的核心挑战不是如何分工而是如何对齐。多个 Agent 之间的认知偏差会逐级放大最终导致协作失败。成功的 Multi-Agent 系统必然有严格的接口契约和结果验收机制。Self-Reflection自我反思Self-Reflection 让 Agent 在执行后自我评估形成迭代改进Action: generate_code(prompt) Output: def foo(): return 1 Reflection: 代码缺少类型注解不符合最佳实践 Revision: def foo() - int: return 1适用场景任务有明确的成功标准反馈机制可自动化如单元测试、代码检查迭代收益大于成本局限自我评估的准确性受模型能力限制模型无法发现自己不知道的问题迭代次数难以预测可能无限循环对简单任务过度设计性价比低Self-Reflection 的前提是Agent 知道什么是好结果。这个标准不能完全交给模型定义必须由工程系统提供客观反馈。Tool Use工具调用Tool Use 是 Agent 的基础能力但作为设计模式时强调的是工具的选择与组合策略User: 分析这个 CSV 文件中的销售数据 Agent: - 工具选择: pandas_reader (数据加载) - 工具选择: data_visualizer (可视化) - 工具组合: 串联执行传递中间结果适用场景工具边界清晰功能正交工具数量可控50个任务可映射到现有工具集局限工具描述质量决定选择准确性描述不当会导致误用工具组合依赖模型推理能力复杂组合易出错工具失败时的降级策略难以设计Tool Use 的本质是能力扩展但它没有解决何时使用的问题。纯粹的 Tool Use 模式需要外部决策系统驱动。代码实战一个完整的 ReAct Agent以下实现一个最小可运行的 ReAct Agent包含工具定义、推理循环和终止判断importjsonimportrefromtypingimportCallable,Dict,List,OptionalclassTool:工具基类def__init__(self,name:str,description:str,func:Callable):self.namename self.descriptiondescription self.funcfuncdefrun(self,args:str)-str:try:returnself.func(args)exceptExceptionase:returnfError:{str(e)}classReActAgent:ReAct Agent 实现PROMPT_TEMPLATEYou are a ReAct agent. Follow this format: Question: the input question Thought: your reasoning step Action: tool_name[args] Observation: tool result ... (repeat Thought/Action/Observation) Thought: I now know the final answer Answer: the final answer Available tools: {tools_desc} Question: {question} {history}def__init__(self,llm_call:Callable[[str],str],tools:List[Tool],max_steps:int10):self.llm_callllm_call self.tools{t.name:tfortintools}self.max_stepsmax_stepsdef_parse_action(self,text:str)-Optional[tuple]:解析 Action 和参数patternrAction:\s*(\w)\[(.*?)\]matchre.search(pattern,text,re.DOTALL)ifmatch:returnmatch.group(1),match.group(2).strip()returnNonedef_parse_final_answer(self,text:str)-Optional[str]:解析最终答案patternrAnswer:\s*(.?)(?:\n|$)matchre.search(pattern,text,re.DOTALL)returnmatch.group(1).strip()ifmatchelseNonedef_build_tools_desc(self)-str:构建工具描述lines[f-{name}:{tool.description}forname,toolinself.tools.items()]return\n.join(lines)defrun(self,question:str)-str:执行推理循环historyforstepinrange(self.max_steps):promptself.PROMPT_TEMPLATE.format(tools_descself._build_tools_desc(),questionquestion,historyhistory)responseself.llm_call(prompt)historyresponse\n# 检查是否得出最终答案answerself._parse_final_answer(response)ifanswer:returnanswer# 解析并执行工具调用actionself._parse_action(response)ifnotaction:historyObservation: Invalid action format\ncontinuetool_name,argsactioniftool_namenotinself.tools:historyfObservation: Unknown tool {tool_name}\ncontinueresultself.tools[tool_name].run(args)historyfObservation:{result}\nreturnfMax steps ({self.max_steps}) reached. Last response:\n{response}# 示例工具defcalculator(expression:str)-str:安全计算数学表达式try:# 仅允许基本数学运算allowedset(0123456789-*/().e )ifnotall(cinallowedforcinexpression):returnError: Invalid characters in expressionreturnstr(eval(expression))exceptExceptionase:returnfError:{str(e)}defsearch_mock(query:str)-str:模拟搜索工具mock_db{python:Python 3.12 released in 2023, with performance improvements,agent:AI Agent is a system with perception, reasoning, and action,react:ReAct pattern: Reasoning Acting interleaving}forkeyinmock_db:ifkeyinquery.lower():returnmock_db[key]returnNo relevant information found# 使用示例if__name____main__:# 模拟 LLM 调用实际使用时替换为真实 APIdefmock_llm(prompt:str)-str:# 简化示例实际应调用 GPT/Claude 等if23inpromptorcalculateinprompt.lower():returnThought: I need to use the calculator\nAction: calculator[23]elifagentinprompt.lower():returnThought: I should search for agent information\nAction: search[AI Agent]returnThought: I now know the final answer\nAnswer: Task completedtools[Tool(calculator,Evaluate math expressions,calculator),Tool(search,Search for information,search_mock)]agentReActAgent(mock_llm,tools)resultagent.run(What is 23?)print(result)这个实现包含以下关键设计严格的格式约束通过正则解析 Action避免模型输出不稳定导致的解析失败步数限制max_steps防止无限循环错误隔离工具执行异常不影响 Agent 主流程历史管理维护完整的 Thought-Action-Observation 链实际生产中需要补充LLM API 接入、更复杂的历史压缩、工具参数验证、并发调用等。Agent 开发框架对比LangChain优势生态最完善工具链丰富抽象层次清晰从简单 Chain 到复杂 Agent文档和社区支持强劣势抽象过度源码阅读成本高版本迭代快API 稳定性差复杂场景下性能调优困难LangChain 适合快速原型验证和标准场景落地。如果需求超出预设抽象扩展成本会显著上升。AutoGen优势Multi-Agent 原生支持角色对话模式自然人机协作设计成熟支持中断和干预Microsoft 背书长期维护有保障劣势单 Agent 场景能力平庸配置复杂学习曲线陡峭调试困难多 Agent 状态追踪成本高AutoGen 适合明确的多角色协作场景。如果不需要 Multi-Agent它的价值难以体现。CrewAI优势角色定义直观Task-Assignment 模式清晰轻量级代码侵入性低快速搭建 Demo 体验好劣势生产级特性不足如容错、监控社区规模小问题解决依赖官方扩展能力受限复杂定制困难CrewAI 适合中小规模项目和快速迭代阶段。大规模生产环境需要自行补齐工程能力。踩坑点无限循环现象Agent 在某个状态反复执行相同 Action无法推进。原因终止条件定义模糊模型无法判断何时结束工具返回结果与预期不符Agent 陷入重试-失败循环规划失败Agent 反复尝试错误的路径解决硬性步数限制如max_steps15状态去重记录已执行 Action重复时强制终止显式终止信号要求模型在满足条件时输出特定标记Token 爆炸现象单次调用 token 数超限或累计成本不可控。原因历史记录无压缩Observation 过长Multi-Agent 通信开销累积工具返回结果未精简解决历史压缩只保留关键 Thought 和最终 Observation工具输出截断限制返回内容长度分层规划高层策略用小模型低层执行用大模型工具调用失败处理现象工具执行异常导致 Agent 中断或输出错误结果。原因工具参数验证缺失模型生成无效输入工具依赖环境不稳定如网络、文件系统错误信息不明确Agent 无法理解失败原因解决工具层防御参数校验 异常捕获 明确错误消息降级策略工具失败时提供替代方案或要求人工干预工具隔离单个工具失败不影响其他工具和主流程作者观点与选型建议Agent 不是万能解它是对确定性工程的补充而非替代。选型决策树任务是否需要运行时决策否 → 传统软件工程不需要 Agent是 → 继续决策路径是否可枚举是 → ReAct单步决策足够否 → 继续任务是否可分解为独立子任务是 → Plan-and-Execute 或 Multi-Agent否 → Self-Reflection 人工监督是否有明确的成功标准和自动化反馈是 → Self-Reflection 可行否 → 降低自动化预期引入人工验收环节框架选择标准场景 快速落地 → LangChain多角色协作 → AutoGen中小规模 快速迭代 → CrewAI特殊需求 团队技术强 → 自研Agent 的成熟度不取决于模型能力而取决于决策边界的设计和工程兜底的能力。把不确定性交给模型把确定性留给工程这是 Agent 落地的核心原则。
很多人以为 Agent 就是让模型自己调工具但这只是冰山一角。Agent 的核心不是自动化而是决策边界的管理。一个真正意义上的 Agent必须回答三个问题何时决策、如何决策、何时停止。如果这三个问题的答案完全由人工预设那不是 Agent是自动化脚本如果完全交给模型那不是 Agent是赌博。Agent 的本质Agent 是一个具备环境感知、自主决策、行动执行、反馈迭代能力的系统。它区别于传统软件的根本特征在于行为路径在运行时确定而非编码时固定。从工程角度看Agent 的本质是决策闭环观测 → 推理 → 行动 → 反馈 → 观测 → ...这个闭环有三个关键参数决策粒度每次行动前是否需要重新规划还是沿用既定策略反馈深度环境反馈是否改变内部状态还是仅作为下一个观测输入终止条件谁来定义任务完成是外部信号还是内部判断很多人把 Agent 理解为LLM 工具调用这忽略了最关键的状态管理和策略演化。一个成熟的 Agent 系统其复杂度不在工具层而在决策层如何让模型在不确定的环境中做出可预期的行为。五种主流 Agent 设计模式ReActReasoning ActingReAct 是最接近人类思维模式的 Agent 架构。其核心机制是思维-行动交替Thought: 我需要查询北京今天的天气 Action: search(北京天气 2026年8月1日) Observation: 北京今天晴气温28-35°C Thought: 用户问的是否适合户外活动我需要判断温度范围 Answer: 适合但需注意防暑适用场景任务可分解为明确步骤环境反馈相对确定性如 API 调用不需要长程规划单步决策即可推进局限无全局规划容易陷入局部最优依赖高质量 Observation环境噪声会放大决策失误Token 消耗随步数线性增长长任务成本高ReAct 的优势在于简单可控劣势在于无前瞻性。它适合走一步看一步的场景不适合需要全局协调的复杂任务。Plan-and-ExecutePlan-and-Execute 将决策拆分为两个阶段先规划再执行。Plan: 1. 收集用户需求文档 2. 分析技术栈选型 3. 生成架构设计方案 4. 输出详细技术文档 Execute: Step 1: 调用文件读取工具获取需求文档 Step 2: 调用知识库检索相关技术方案 ...适用场景任务有明确起点和终点步骤间依赖关系清晰执行环境相对稳定无需频繁调整计划局限计划阶段的质量决定上限一次规划失误会导致全盘失败执行阶段缺乏灵活调整能力环境变化时需要重新规划过度依赖初始信息新信息难以动态融入Plan-and-Execute 的本质是用确定性对抗不确定性。它假设环境足够稳定规划足够准确这在很多场景下是强假设。Multi-Agent多智能体协作Multi-Agent 将复杂任务拆解到多个 Agent每个 Agent 承担特定角色[ProductManager] 接收用户需求生成产品文档 [TechLead] 审查文档生成技术方案 [Developer] 实现方案输出代码 [Tester] 执行测试反馈问题适用场景任务复杂度超出单 Agent 决策能力需要跨领域知识协作有明确的角色分工和协作流程局限协调成本高Agent 间通信开销大角色边界模糊时会产生推诿或重复劳动整体稳定性取决于最弱环节Multi-Agent 的核心挑战不是如何分工而是如何对齐。多个 Agent 之间的认知偏差会逐级放大最终导致协作失败。成功的 Multi-Agent 系统必然有严格的接口契约和结果验收机制。Self-Reflection自我反思Self-Reflection 让 Agent 在执行后自我评估形成迭代改进Action: generate_code(prompt) Output: def foo(): return 1 Reflection: 代码缺少类型注解不符合最佳实践 Revision: def foo() - int: return 1适用场景任务有明确的成功标准反馈机制可自动化如单元测试、代码检查迭代收益大于成本局限自我评估的准确性受模型能力限制模型无法发现自己不知道的问题迭代次数难以预测可能无限循环对简单任务过度设计性价比低Self-Reflection 的前提是Agent 知道什么是好结果。这个标准不能完全交给模型定义必须由工程系统提供客观反馈。Tool Use工具调用Tool Use 是 Agent 的基础能力但作为设计模式时强调的是工具的选择与组合策略User: 分析这个 CSV 文件中的销售数据 Agent: - 工具选择: pandas_reader (数据加载) - 工具选择: data_visualizer (可视化) - 工具组合: 串联执行传递中间结果适用场景工具边界清晰功能正交工具数量可控50个任务可映射到现有工具集局限工具描述质量决定选择准确性描述不当会导致误用工具组合依赖模型推理能力复杂组合易出错工具失败时的降级策略难以设计Tool Use 的本质是能力扩展但它没有解决何时使用的问题。纯粹的 Tool Use 模式需要外部决策系统驱动。代码实战一个完整的 ReAct Agent以下实现一个最小可运行的 ReAct Agent包含工具定义、推理循环和终止判断importjsonimportrefromtypingimportCallable,Dict,List,OptionalclassTool:工具基类def__init__(self,name:str,description:str,func:Callable):self.namename self.descriptiondescription self.funcfuncdefrun(self,args:str)-str:try:returnself.func(args)exceptExceptionase:returnfError:{str(e)}classReActAgent:ReAct Agent 实现PROMPT_TEMPLATEYou are a ReAct agent. Follow this format: Question: the input question Thought: your reasoning step Action: tool_name[args] Observation: tool result ... (repeat Thought/Action/Observation) Thought: I now know the final answer Answer: the final answer Available tools: {tools_desc} Question: {question} {history}def__init__(self,llm_call:Callable[[str],str],tools:List[Tool],max_steps:int10):self.llm_callllm_call self.tools{t.name:tfortintools}self.max_stepsmax_stepsdef_parse_action(self,text:str)-Optional[tuple]:解析 Action 和参数patternrAction:\s*(\w)\[(.*?)\]matchre.search(pattern,text,re.DOTALL)ifmatch:returnmatch.group(1),match.group(2).strip()returnNonedef_parse_final_answer(self,text:str)-Optional[str]:解析最终答案patternrAnswer:\s*(.?)(?:\n|$)matchre.search(pattern,text,re.DOTALL)returnmatch.group(1).strip()ifmatchelseNonedef_build_tools_desc(self)-str:构建工具描述lines[f-{name}:{tool.description}forname,toolinself.tools.items()]return\n.join(lines)defrun(self,question:str)-str:执行推理循环historyforstepinrange(self.max_steps):promptself.PROMPT_TEMPLATE.format(tools_descself._build_tools_desc(),questionquestion,historyhistory)responseself.llm_call(prompt)historyresponse\n# 检查是否得出最终答案answerself._parse_final_answer(response)ifanswer:returnanswer# 解析并执行工具调用actionself._parse_action(response)ifnotaction:historyObservation: Invalid action format\ncontinuetool_name,argsactioniftool_namenotinself.tools:historyfObservation: Unknown tool {tool_name}\ncontinueresultself.tools[tool_name].run(args)historyfObservation:{result}\nreturnfMax steps ({self.max_steps}) reached. Last response:\n{response}# 示例工具defcalculator(expression:str)-str:安全计算数学表达式try:# 仅允许基本数学运算allowedset(0123456789-*/().e )ifnotall(cinallowedforcinexpression):returnError: Invalid characters in expressionreturnstr(eval(expression))exceptExceptionase:returnfError:{str(e)}defsearch_mock(query:str)-str:模拟搜索工具mock_db{python:Python 3.12 released in 2023, with performance improvements,agent:AI Agent is a system with perception, reasoning, and action,react:ReAct pattern: Reasoning Acting interleaving}forkeyinmock_db:ifkeyinquery.lower():returnmock_db[key]returnNo relevant information found# 使用示例if__name____main__:# 模拟 LLM 调用实际使用时替换为真实 APIdefmock_llm(prompt:str)-str:# 简化示例实际应调用 GPT/Claude 等if23inpromptorcalculateinprompt.lower():returnThought: I need to use the calculator\nAction: calculator[23]elifagentinprompt.lower():returnThought: I should search for agent information\nAction: search[AI Agent]returnThought: I now know the final answer\nAnswer: Task completedtools[Tool(calculator,Evaluate math expressions,calculator),Tool(search,Search for information,search_mock)]agentReActAgent(mock_llm,tools)resultagent.run(What is 23?)print(result)这个实现包含以下关键设计严格的格式约束通过正则解析 Action避免模型输出不稳定导致的解析失败步数限制max_steps防止无限循环错误隔离工具执行异常不影响 Agent 主流程历史管理维护完整的 Thought-Action-Observation 链实际生产中需要补充LLM API 接入、更复杂的历史压缩、工具参数验证、并发调用等。Agent 开发框架对比LangChain优势生态最完善工具链丰富抽象层次清晰从简单 Chain 到复杂 Agent文档和社区支持强劣势抽象过度源码阅读成本高版本迭代快API 稳定性差复杂场景下性能调优困难LangChain 适合快速原型验证和标准场景落地。如果需求超出预设抽象扩展成本会显著上升。AutoGen优势Multi-Agent 原生支持角色对话模式自然人机协作设计成熟支持中断和干预Microsoft 背书长期维护有保障劣势单 Agent 场景能力平庸配置复杂学习曲线陡峭调试困难多 Agent 状态追踪成本高AutoGen 适合明确的多角色协作场景。如果不需要 Multi-Agent它的价值难以体现。CrewAI优势角色定义直观Task-Assignment 模式清晰轻量级代码侵入性低快速搭建 Demo 体验好劣势生产级特性不足如容错、监控社区规模小问题解决依赖官方扩展能力受限复杂定制困难CrewAI 适合中小规模项目和快速迭代阶段。大规模生产环境需要自行补齐工程能力。踩坑点无限循环现象Agent 在某个状态反复执行相同 Action无法推进。原因终止条件定义模糊模型无法判断何时结束工具返回结果与预期不符Agent 陷入重试-失败循环规划失败Agent 反复尝试错误的路径解决硬性步数限制如max_steps15状态去重记录已执行 Action重复时强制终止显式终止信号要求模型在满足条件时输出特定标记Token 爆炸现象单次调用 token 数超限或累计成本不可控。原因历史记录无压缩Observation 过长Multi-Agent 通信开销累积工具返回结果未精简解决历史压缩只保留关键 Thought 和最终 Observation工具输出截断限制返回内容长度分层规划高层策略用小模型低层执行用大模型工具调用失败处理现象工具执行异常导致 Agent 中断或输出错误结果。原因工具参数验证缺失模型生成无效输入工具依赖环境不稳定如网络、文件系统错误信息不明确Agent 无法理解失败原因解决工具层防御参数校验 异常捕获 明确错误消息降级策略工具失败时提供替代方案或要求人工干预工具隔离单个工具失败不影响其他工具和主流程作者观点与选型建议Agent 不是万能解它是对确定性工程的补充而非替代。选型决策树任务是否需要运行时决策否 → 传统软件工程不需要 Agent是 → 继续决策路径是否可枚举是 → ReAct单步决策足够否 → 继续任务是否可分解为独立子任务是 → Plan-and-Execute 或 Multi-Agent否 → Self-Reflection 人工监督是否有明确的成功标准和自动化反馈是 → Self-Reflection 可行否 → 降低自动化预期引入人工验收环节框架选择标准场景 快速落地 → LangChain多角色协作 → AutoGen中小规模 快速迭代 → CrewAI特殊需求 团队技术强 → 自研Agent 的成熟度不取决于模型能力而取决于决策边界的设计和工程兜底的能力。把不确定性交给模型把确定性留给工程这是 Agent 落地的核心原则。
)
