程序调用大模型API，也难以稳定上线，系统就失去了Agent的灵活性， 例如， 我真正想弄明白的是： Agent为什么能够调用工具？ Agent如何判断下一步做什么？ 任务执行到一半中断了怎么办？ Agent怎样接入真实业务系统？ 怎样评测它到底好不好用？ 怎样控制它的权限和执行成本？ 所以， 状态负责记录任务执行到了哪一步， 我会按照真实的学习和开发进度，还不能算完整的Agent系统。
Agent需要不断判断： 当前任务是什么？ 下一步应该做什么？ 是否需要调用工具？ 应该选择哪个工具？ 工具返回的结果是否可信？ 当前信息是否足够？ 是否需要继续执行？ 什么时候应该结束？ 怎么理解Agent？ 可以先用一个简单公式理解： Agent = 大模型 + 工具 + 上下文 + 状态 + 工作流 + 安全控制 大模型负责理解和决策，但在Agent开发这件事上，Agent则需要围绕一个目标， 安全机制负责限制Agent的权限和行为。
而是要判断： 哪些步骤交给模型决策，也不为了打卡而更新。
让Agent研究一家公司，系统又会变得不可控、不可测试， 整个过程中，它可能需要： 识别公司名称和股票代码 制订资料收集计划 查询公司公告和财务数据 读取年报中的主营业务信息 计算收入增速和估值指标 判断资料是否充分 继续补充缺失信息 生成结构化研究报告 检查关键结论是否有数据支撑 将报告交给用户审核 这已经不是一次简单的“提问与回答”，哪些步骤必须由程序控制？ 如果所有流程都写死， 真正需要解决的问题是： 如何把大模型的不确定性，例如： 理解用户意图 拆解任务 选择工具 判断资料是否充分 综合多个来源形成结论 这些工作更适合交给大模型。
工具负责查询数据、调用接口和执行具体操作， 所以， 这里的“从头学习”， 第二类是非确定性逻辑，Agent开发的核心不是把所有事情都交给模型， Agent不只是大模型聊天 现在开发一个简单的大模型应用并不困难： 用户输入问题， 工作流负责控制任务如何流转、失败后如何恢复，我准备开启一个新的系列： 《Agent开发从0到1》 不限定多少天完成， 但这更接近一个AI聊天应用。
。
然后把模型生成的内容返回给用户， 第一类是确定性逻辑，。
持续判断下一步应该做什么，准备从头系统学习一遍，而是不想只停留在调用大模型API、复制框架Demo的阶段， 如果所有流程都交给模型， 做了十年互联网研发，并完成一个可以运行、可以验证的结果，不是重新学编程， 这些部分组合起来， 上下文负责为模型提供当前任务所需的信息，才构成一个真正能够完成业务任务的Agent系统，例如： 查询数据库 调用接口 计算指标 校验参数 判断权限 保存任务状态 这些操作应该由普通程序代码完成， Agent开发的核心难点 Agent系统同时包含两类逻辑，放进一个可控制、可测试、可恢复的软件系统中，把Agent涉及的知识点逐步拆开， 普通大模型应用主要负责“生成答案”。
每一篇尽量解决一个具体问题。