从 LLM 到 Agent：“工具”和“主动性”？

最近AI概念实在是太火后端java仔不得不跟上时代。从大语言模型出现以后人们发现它可以写论文、写代码、做总结、回答问题表现得非常强大。但在实际使用中也逐渐暴露出几个明显问题第一幻觉严重。它可能会生成看似合理、但实际上并不存在的信息。第二只能生成文本。它本身不会真正查数据库、读文件、运行代码、操作网页。第三无法天然获取实时信息。比如“明天天气怎么样”“从这里到成都东站怎么走”如果没有外部工具它只能凭已有知识猜测甚至可能胡编。因此后来逐渐出现了 RAG、Function Calling、MCP、Skills 等机制本质上都是给 LLM 接上外部工具让它不再只是“会说话”而是可以“查资料、调用工具、观察结果、继续决策”。这时LLM 就开始从一个单纯的问答模型逐渐演变成一个 Agent。1. 什么是 Agent智能体是从传统的基于强化学习基于大数据到目前非常主流的基于llm的智能体。简单来说Agent 不是单纯的大模型而是一个由 LLM、工具、记忆、规划、执行和反馈机制共同组成的智能任务系统。如图所示来源传统的 LLM 是用户问一句 → LLM 回一句 → 结束而 Agent 是用户给目标LLM -理解任务 -Planner -拆解步骤Executor - 调用工具Observer -返回结果LLM -继续判断下一步直到任务完成这里个人觉得最大的变化是一个主动性他在不断的反馈给llm 下一步要干啥任务怎么拆解Agent 并不是 LLM 自己主动想干什么而是程序一次又一次地把问题丢给 LLM让它选择下一步Agent 的主动性就是外部程序不断问 LLM 这句话 : 下一步需要做啥LLM 本身没有“自我启动能力”真正的主动触发来自外部调度器、事件监听器、工作流系统。所以agent一般由一下部分组成1. LLM负责理解、推理、规划、决定下一步2. Tools负责搜索、读文件、查数据库、写代码、发邮件等3. Memory保存长期信息、历史任务、用户偏好4. Planner把大任务拆成小步骤5. Executor真正执行工具调用6. Observer把执行结果反馈给 LLM7. Controller决定什么时候继续什么时候停止而好的一个agent就是怎么让 LLM 在复杂任务中稳定、正确、可控地决定“下一步该做什么”。难点就是分为以下几点1. 任务拆解难后文会根据中兴的co-sight agent为例看大团队是如何解决的LLM 很容易把任务拆得太粗、太细、顺序不合理或者遗漏关键步骤2.工具选择难Agent 面前可能有很多工具PDF 阅读工具代码执行工具邮件工具3.工具调用结果理解难工具返回的结果不一定干净4.状态管理难Agent 不是一步完成任务而是多步执行。对应的优化点可以是第一是规划优化。复杂任务不能直接生成答案而要先拆解成若干子任务明确每一步的目标、所需工具和完成条件。第二是工具路由优化。要为每个工具定义清晰的功能、输入输出和适用场景同时结合规则、分类模型或 LLM 判断选择最合适的工具。第三是检索和工具参数优化。对于搜索或向量数据库ps光是向量数据库的设计就很复杂了不能直接使用用户原话而要进行 query rewriting、多路检索、过滤和重排提高返回结果的相关性。第四是状态和记忆优化。Agent 需要显式维护当前任务状态包括用户目标、约束、已完成步骤、待完成步骤和中间结论避免长任务中遗忘或跑偏。第五是验证和终止优化。Agent 在输出前应检查结果是否满足用户要求并设置完成标准和最大执行边界避免信息不足或无限循环。第六是安全和成本优化。对工具进行风险分级低风险工具自动执行高风险动作必须用户确认openclaw不是出现过删除用户数据的事故吗感觉就是权限没设计好同时限制调用次数、缓存结果降低成本和延迟。所以我认为 Agent 落地的关键是把 LLM 的推理能力、工具的执行能力和工程上的状态控制、安全控制、结果验证结合起来。2.Co-Sight解读来看一个标准agent的优秀案例代码地址https://github.com/ZTE-AICloud/Co-Sight/是一个“面向复杂调研任务的 Deep Research Agent 框架”是一个调研型 Agent 框架报告生成只是它的最终表现形式他的代码结构如下Co-Sight ├── app │ ├── agent_dispatcher │ ├── common │ └── cosight ├── cosight_server │ ├── deep_research │ ├── manus_server │ ├── sdk │ └── web ├── config ├── tools ├── CoSight.py └── llm.py从CoSight.py看它初始化了几个关键对象plan_llm act_llm tool_llm vision_llm TaskPlannerAgent TaskActorAgent TaskManager Plan也就是说它不是一个 LLM 干所有事情而是把模型角色拆开了规划模型、执行模型、工具模型、视觉模型。代码里也分别配置了llm_for_plan、llm_for_act、llm_for_tool、llm_for_vision即图片来源gpt-image用户问题 ↓ TaskPlannerAgent负责任务规划 ↓ Plan / TaskManager维护任务状态 ↓ TaskActorAgent执行具体步骤 ↓ Tools / MCP / Search获取外部信息 ↓ TRSF整理结构化事实 ↓ CAMV冲突验证 ↓ Planner finalize生成最终报告最关键的机制是TRSF 负责持续组织、验证、同步多个 Agent 之间的证据CAMV 把验证转化为“识别冲突 针对性证伪”只把计算资源放在不同 expert agents 的分歧点上即TRSF 把搜索/工具结果变成“有来源、有证据、可追溯”的事实账本CAMV 它解决的问题是多个 Agent 或多个资料来源可能说法不一致但不会把所有资料全部重新检查一遍而是专门盯住冲突点然后它针对这个冲突去验证。源代码中并没有这个两个命名的py文件这是中兴发表的论文提出的两个概念。对于agent来说还有个很重要的点就是如何设计他的上下文保持记忆和理解任务状态。1. 系统角色 你是一个 Agent目标是完成任务不是闲聊。 2. 用户目标 用户到底要你完成什么。 3. 当前状态 已经做了什么查到了什么还剩什么。 4. 可用工具列表 你有哪些工具每个工具干什么输入格式是什么。 5. 约束条件 不能做什么哪些操作要确认输出格式是什么。 6. 上一轮工具结果 刚刚调用工具返回了什么。 7. 下一步决策要求 请判断继续调用工具还是输出最终答案。以 Co-Sight 为例它不是让 LLM 自己记住所有东西而是用plan_id Plan TaskManager保存任务状态不是让 LLM 天然知道工具而是通过搜索配置和 MCP skill 配置把工具暴露给它每一轮执行时再把当前任务、当前步骤、工具信息和已有状态喂给对应角色的 LLM。如果要自己开发一个agent我们可以不用自己重复造一般可以用很火的langChain框架它是一个开发LLM相关业务功能的集大成者是一个Python的第三方库提供了各种功能的API。常见的LongChain是AgentExecutor、Tool、Chain、Runnable、LangGraph。其中面试经常会问LangGraph 更偏复杂 Agent 编排多智能体协作这些。仔细阅读 Co-Sight会发现他自己写了 Agent 编排逻辑t 没有主要依赖 LangChain 来搭 Agent Loop。是自研了一套面向 Deep Research 的 Agent 编排框架。它通过 Planner–Actor 架构完成任务拆解和执行通过TaskManager/Plan维护任务状态其中会话管理是一个很重要的概念很多公司的核心和基础业务。并通过 MCP skill 接入外部工具。LangChain 这类框架也能实现类似能力但 Co-Sight 的重点在于自定义的多 Agent 协作、结构化事实和冲突验证机制。向量数据库可以理解为是llm调用的一个很很重要的工具RAG/向量检索的核心链路分片Chunking把长文档切成小块方便检索→ 召回Recall从所有 chunk 中找出“可能相关”的一批→ 排序Ranking对召回结果再精排找出“最相关、最靠谱”的。常见的排序方式1. 向量相似度排序基础2. Cross-Encoder更精准3. LLM rerank最强但贵未完待续。。。。