去年我接手过一个日志分析需求。按以前的习惯我会写一个 Python 脚本先连上 ES构造 query DSL把时间范围、聚合条件、索引 pattern 全部写死再处理分页和异常重试最后输出一个汇总报告。整套流程大概要花两三个小时。后来试了试用 AI Agent 直接对接 ES REST API 做同样的智能日志分析流程确实被压缩了但痛苦并没有完全消失。它不是不会写代码而是会“自信地”用错聚合字段在错误的方向上反复分析十几轮。这让我重新思考一个问题AI Agent 编程与传统编程之间到底是一次工具升级还是一次思维方式的跃迁标题里那个词“古法编程”初看像调侃细想却很准确。我们过去熟悉的编程方式本质上是一种手工管理确定性的手艺变量、函数、状态、异常、边界全都要由开发者亲手控制。而 AI Agent 开发正在把这种控制权交给模型、交给运行时、交给一组更抽象的设计原则。本文想聊的不是“用 AI 写代码有多爽”而是这场跃迁真正改变了什么、保留了什么以及从古法编程走过来的人如何在新范式里建立新的能力模型。1. 先回答一个问题为什么 AI 时代写代码反而变得更难了这几年有个很常见的现象很多人第一次接触 AI 编程时会觉得“代码不再是瓶颈了”几个月后却又发现真正难的不是让 AI 写出代码而是让 AI 稳定地做对事情。这个反差恰恰是理解 AI Agent 开发的关键入口。1.1 从“写代码”到“驾驭不确定性”传统编程里开发者面对的是确定性问题。函数输入明确输出可预期异常能被 try-catch 捕获状态可以通过变量和锁来管理。你写的每一行代码本质上都是在对计算机说按这个顺序执行按这个规则处理按这个分支返回。这套方式的最大优点是结果可复现。只要输入相同执行相同输出大概率也相同。AI Agent 开发完全不是这个逻辑。Agent 接收的是一个目标、一组工具、一些上下文然后由大模型逐步决策先调用哪个工具、给什么参数、看到结果后如何调整。这个过程是可变的、概率性的。同一个 prompt同一个工具列表今天跑和明天跑中间路径可能完全不同结果也可能有细微差异。这意味着什么意味着过去“代码跑不通就看报错信息”的调试方式在 Agent 场景下经常失效。因为它不是报错而是“不按预期做”。日志也能看到工具调用记录但分析起来比传统堆栈难得多因为你面对的不再是一条确定的执行路径而是一棵不断分叉的决策树。1.2 为什么“古法编程”的经验没有过时很多人以为 AI Agent 开发会让传统编程能力变得不重要这个判断我不同意。恰恰相反传统编程积累的经验在 Agent 时代变成了更稀缺的能力只是它从“写业务逻辑”变成了“设计约束和评估结果”。比如一个常规的 ES 日志分析 Agent。你要让它稳定工作就得给它设计清晰的工具接口索引名、时间字段、聚合字段、过滤条件、返回格式。这些不是 prompt 技巧而是从传统编程里带过来的接口设计能力。再看工具调用后的结果校验聚合返回空数组是索引名错了、时间范围为空、还是字段类型不匹配这种排查思路本质上还是传统编程里的分而治之、逐层定位。所以在标题里“古法编程”不是一个贬义词。它更像是一个坐标系只有理解了传统编程中确定性、状态管理、错误处理是怎么运作的你才会真正理解 AI Agent 为什么强大又为什么脆弱。2. AI Agent 开发真正改变的是开发者与逻辑的关系传统编程里开发者是逻辑的实现者AI Agent 开发里开发者变成了逻辑的定义者和观察者。这个转变不是修辞问题它会直接影响你的工程设计方式。2.1 核心变化从“手工控制流程”到“意图驱动决策”先做一组对账理解两种开发方式的差异维度古法编程AI Agent 开发核心产物源代码、可执行程序目标定义、工具集合、约束规则、评估反馈流程控制开发者显式控制分支和循环模型基于上下文动态决策状态管理变量、数据库、缓存对话上下文、短期记忆、长期记忆错误处理try-catch、重试、回滚行为纠偏、约束兜底、人类介入调试方式断点、堆栈、日志工具调用链、决策轨迹、输出评审稳定性来源类型系统、测试、代码审查提示词质量、工具边界、评估闭环这张表不是要贬低哪一方。传统编程适合确定性强、性能敏感、可维护性要求高的业务逻辑Agent 开发适合流程灵活、目标复杂、传统规则难以穷举的任务。关键在于你不能再用“写代码”的思路去写 Agent否则做出来的只是一个套了层 prompt 的脚本。2.2 Agent 里的“三件套”模型、工具、上下文很多刚接触 Agent 开发的同学会把注意力全放在模型选择上认为“只要模型够强Agent 就好用”。实际工程里模型只是决策大脑真正决定 Agent 上限的往往是你给它配了什么工具、以及怎么管理上下文。工具是什么是 Agent 与外部世界交互的接口。它可以是 REST API、数据库查询、代码解释器、文件读写、内部搜索服务。工具设计的好坏直接决定模型能不能准确调用。一个常见错误是把工具设计得过于通用参数太多、返回结构太复杂、错误信息不够直白。模型不是人它不会像熟练工程师那样去猜“这个参数大概率是那个意思”它只会基于 prompt 和工具描述做选择。工具描述写得含糊它就会在错误参数上反复试探。上下文又是另一层关键。Agent 的上下文窗口不是无限的。你给它的对话历史、工具返回结果、用户目标加起来会迅速膨胀。在实际项目中一定要思考哪些信息必须常驻哪些信息按需加载哪些信息用完就丢。可以把这理解成“先给目录再按需展开章节”而不是把所有资料一次性塞进模型脑子里。2.3 异步、并发与 Agent 的真实运行形态在热词里异步编程、CompletableFuture 异步编程异常处理这类关键词高频出现。放在 Agent 开发语境下这些传统并发工具反而变得更重要了。因为真实的 Agent 系统很少是单轮问答。更多场景是一个 Agent 在后台分析日志同时另一个 Agent 在汇总报表还有一个 Agent 在等待外部系统回调。这种编排方式用传统同步代码很难写出稳定高效的实现。更合理的做法是把每个 Agent 任务封装成异步单元用任务队列控制调度用超时机制防止个别 Agent 卡死。如果你以前写过 CompletableFuture 的异常处理就会知道这类异步链路的难点不是启动任务而是在某一个环节失败时如何取消后续依赖、如何记录失败原因、如何让整个流程回到安全状态。这个经验在 Agent 工程里同样成立。所以我的观点是AI Agent 开发不是抛弃编程基础而是把传统编程里的设计模式重新映射到新的决策式运行时上。3. Agent 开发者的新能力框架不是“会写代码”而是“会设计行为”如果上面说清楚了变化那接下来就要解决一个更实际的问题一个从古法编程转型到 AI Agent 开发的人应该重点培养哪些能力我把它拆成四个维度目标拆解、工具契约、约束兜底、评估反馈。这也是我自己做 Agent 项目时反复使用的框架。3.1 目标拆解把模糊任务变成 Agent 可执行的计划很多 Agent 项目失败不是模型不强而是任务定义太模糊。比如“帮我把这个系统日志分析清楚”这种目标交给任何 Agent 都很难做好。因为它没有明确输入边界、分析维度、输出格式和异常处理预期。正确的做法是先像做传统需求分析一样拆出子任务日志来源ES 索引、文件、数据库对应不同数据访问工具。时间范围最近 30 分钟、指定时间段、还是全部决定了查询参数。分析维度错误类型、服务名、接口耗时、来源 IP决定了聚合字段。产出形式纯文本摘要、表格、还有异常明细决定了输出格式。异常处理ES 返回空、查询超时、字段不存在时Agent 该怎么办这一步做完Agent 的 prompt 其实已经完成 50% 了。它不是提示词技巧而是需求分析功底。3.2 工具契约让每个工具都像函数签名一样清晰我见过很多 Agent 项目里工具描述写得很随意比如“查询日志”三个字。模型对这样的工具毫无把握只能靠猜。更稳妥的做法是把每个工具当成一个 API 来设计内容示例工具名称search_es_logs功能描述按时间范围和关键词查询 ES 日志返回最近 N 条结果参数说明index、start_time、end_time、keyword、size返回值结构status、total、items 数组错误信息明确的错误码和可读描述这样的工具契约有几个好处模型更容易理解何时调用这个工具、传什么参数开发者更容易检查工具调用是否合理即使模型出错你也能从参数日志里快速定位问题。本质上这就是把类型系统和接口签名思想迁移到了 Agent 工具层。3.3 约束兜底不要指望模型永远“听话”再强的模型也会在特定场景下做出你意料之外的选择。所以 Agent 工程里一定要有约束层和兜底层。约束层包括最大迭代次数避免模型在错误路径上无限循环。工具白名单只开放 Agent 真正需要调用的工具。参数校验模型生成的参数先过一层格式校验再真正执行。敏感操作审批删除、写入、发布等危险动作强制人工确认。兜底层则是当 Agent 行为偏离预期时系统如何恢复。常见的手段包括重置上下文重新执行、回退到上一步人工接管、把异常路径记录下来作为后续优化样本。把这些东西想清楚Agent 才具备最基本的工程可用性而不只是一个 demo。3.4 评估反馈没有指标就无法持续优化传统开发有单元测试、集成测试、覆盖率Agent 开发也需要自己的评估体系。但这个体系不是简单的“对错判断”而是对行为质量的评估。可以从几个维度建立 Agent 的评估日志任务完成率最终是否给出了用户要的结果。工具调用有效性调用的工具中有多大比例是必要的、正确的。路径效率从开始到完成是否走了大量无效步骤。结果稳定性相同输入下多次运行结果是否保持一致。人类介入率多少次任务需要人工纠正。这些指标不需要第一天就全部搭好。但项目一旦要从 demo 走向长期使用评估反馈就是最值得投入的部分。它决定了你是靠运气维护一个 Agent还是靠数据持续优化一套系统。4. 从零跑通一个 Agent最小可用流程与关键参数理论讲再多不如动手跑一个最小流程。下面我用一个常见场景来说明构建一个能通过 REST API 智能分析日志的 Agent。项目很小但足以覆盖绝大多数 Agent 开发的核心环节。注意下面涉及的具体参数和代码是示例结构不是某个官方标准答案。落地时请以你实际使用的模型、框架和日志服务为准。4.1 环境准备先选运行时再写 prompt你可以选择使用 Hugging Face 提供的 Agent 相关术语和框架也可以使用市面上其他成熟的 Agent 开发库。无论选哪个核心关注点是一样的它是否支持工具定义、是否支持对话循环、是否能接入你已有的日志接口。环境准备通常包含Python 3.10 及以上版本。Agent 开发库或框架比如 transformers 相关组件、LangChain、LlamaIndex或更轻量的自定义实现。ES 客户端库比如 elasticsearch-py用于通过 REST API 查询日志。一个大模型 API 或本地模型服务用于 Agent 的决策引擎。如果只是学习和小规模验证默认配置通常够用。如果要长期使用还要考虑模型调用成本、并发上限、日志存储和权限控制。4.2 最小流程定义工具、编排循环、验证输出一个最小 Agent 流程可以拆成四步第一步定义日志查询工具。这个工具不需要复杂只要封装一个函数接收索引名、时间范围、关键词返回日志列表和聚合结果。def search_es_logs(index, start_time, end_time, keywordNone, size20): # 实际实现里这里会构造 ES query DSL # 然后通过 elasticsearch-py 发起 GET /{index}/_search pass第二步让 Agent 知道这个工具的存在。在 Agent 框架里通常需要给它配置工具描述包括名称、用途、参数结构。描述越清晰模型调用越准确。第三步设计主循环。这一步通常由框架封装但你要理解它的流程接收用户目标 → 模型决定调用哪个工具 → 执行工具 → 把结果返回给模型 → 模型决定下一步。最多迭代 N 轮后结束输出最终结论。第四步把整个流程包成一个入口函数方便后续复用。def run_log_analysis_agent(question: str) - str: # 1. 初始化工具列表 # 2. 拼接系统 prompt 和用户问题 # 3. 循环执行 Agent 推理 # 4. 返回最终结果 pass这个流程跑通后你才算真正完成了从“古法编程”到“Agent 开发”的第一步。后续再考虑批量任务、并发调度、日志存储和异常告警。4.3 关键参数不要一上来调满很多 Agent 框架会暴露一堆参数新手容易陷入调参焦虑。我建议先关注四个最关键的模型选择优先选指令跟随能力强、工具调用稳定的模型。温度 temperature分析类任务建议偏低比如 0.1 到 0.3减少随机性。最大迭代轮数 max_iterations不要设太大建议 5 到 10 轮防止死循环。上下文窗口管理明确哪些历史轮次可以裁剪哪些工具返回值需要截断。这些参数没有绝对标准但要结合场景判断。如果任务确实复杂轮数可以放宽如果追求稳定输出温度就应该压低。核心原则是让 Agent 在“足够灵活的路径”和“足够稳定的结果”之间找到平衡。5. 新手最容易误判的四件事从传统编程转过来的人常常会把 Agent 开发理解成“多了一个写代码的助手”。在真正落地时会发现它更像是在驯化一套新的运行系统。下面这四个误区我见过太多次。5.1 误区一把 prompt 当成万能网上有很多“万能 prompt”模板但实际项目中prompt 的作用更像一个初始设定不能替代工具设计和上下文管理。一个 Agent 能不能稳定完成日志分析更多取决于工具返回的数据结构、错误信息是否清晰。Prompt 写得再花哨工具返回一堆含糊的 JSON模型照样会理解偏差。5.2 误区二忽略 Agent 调用外部服务时的权限边界传统开发写代码权限控制通常在代码里显式声明。Agent 开发则容易陷入另一种极端为了让模型更自由地完成任务把权限放得很宽。这非常危险。一旦 Agent 调用了不该调的接口或者批量执行了错误操作后果可能比传统代码更难以掌控。更稳妥的做法是给 Agent 最小权限所有非只读操作默认禁止需要时单独授权。5.3 误区三拿“单次跑通”当“长期可用”今天跑通一个 Agent 任务明天再跑一次结果可能完全不一样。这种不稳定让很多程序员抓狂。但这是 Agent 开发的固有特征不是 bug。要接受它然后用评估、日志、约束去收窄波动范围而不是指望某一套 prompt 能一劳永逸。5.4 误区四把上下文当成无限容量模型的上下文窗口虽然在变大但真实工程里塞入过多信息反而会让决策质量下降。更好的方式是对信息做分层用户目标、核心约束放在开头动态查询结果按需载入历史决策轨迹用于纠偏。这本质上是对信息架构的能力而不是 prompt 的堆砌能力。6. 排查链路Agent 不按预期执行时该查哪一层Agent 项目一旦出问题传统调试思维会直接失效因为很多时候没有报错只有“结果不对”或“路径不对”。我给自己总结了一套排查顺序从现象往下逐层定位。6.1 先看现象是“无结果”“错结果”还是“路径异常”无结果Agent 不知道下一步该做什么或者调用了工具但没有产出。错结果流程跑通了工具也调了但最终结论与事实不符。路径异常结果可能对但过程走了大量无效轮次或者调用了不该调的工具。三种现象指向不同层级。无结果通常发生在上下文或工具描述层错结果通常发生在模型判断或工具返回层路径异常往往和约束层有关。6.2 再看输入与上下文检查用户问题是否清晰系统 prompt 是否包含必要约束。再检查上下文里有没有历史干扰信息。比如前一轮分析失败错误信息是否残留到了下一轮导致后续判断被带偏。一个常见问题是Agent 在前几轮工具调用里收到了大量原始日志上下文被塞满结果在后续步骤里反而抓不住重点。6.3 再看工具本身看工具描述与实际实现是否一致返回的数据结构是否在 prompt 里有明确说明。一个高频问题是工具返回的字段名和描述不一致导致模型无法把结果映射到下一步。这时不需要改模型只需要把工具返回格式对齐到描述即可。6.4 最后看模型行为与统计基线如果前几层都没问题就要记录模型的决策轨迹统计它在哪些步骤上反复横跳、哪些问题类型容易出错。通过一批样本建立基线之后你才能判断这轮改动是真正提升了稳定性还是碰巧运气好。记住一个原则不要靠调整 prompt 去修所有问题。先定位是工具契约、上下文管理、还是约束层的问题再决定怎么改。7. 传统编程功底在这个时代反而更值钱最后想回到标题。有人把“古法编程”说得很emo好像不马上转 AI Agent 就会被淘汰。但在我的观察里真正做得好 Agent 项目的人恰恰是那些在传统编程里积累了大量基本功的人。只不过他们的能力标签变了不再是“某个框架写得很熟”而是“能把模糊问题拆清楚能让 AI 在可控范围内发挥”。7.1 双栈能力一边通传统工程一边懂模型行为未来几年Agent 开发者更像是一个“双栈工程师”。传统一栈是工程能力接口设计、数据建模、并发处理、监控告警新一栈是模型能力prompt 设计、工具调用策略、上下文管理、行为评估。这两者不是替代关系。工程能力负责给 Agent 划边界模型能力负责让 Agent 在边界内聪明地完成任务。任何一端缺失Agent 项目都会出问题。如果只懂 prompt 不懂工程你做不出稳定可维护的系统如果只懂工程不碰模型你很难理解为什么 Agent 会“不听话”。7.2 下一步最该做什么不用焦虑不用一口气学十几个工具。我建议按照这样的顺序行动拿一个你熟悉的重复性任务比如日志聚类、报表生成、服务状态巡检。先按传统方式拆好需求明确输入、输出和规则。用最简单的方式定义一个工具让 Agent 调一次 API。跑通单次流程后再给 Agent 加上失败重试、上下文清理和最大迭代限制。保存所有运行记录建立自己的评估样本集。这个过程做完你对 AI Agent 开发的理解会比看十篇入门教程更扎实。因为它不再是一个概念而成了一套你已经跑通过、也踩过坑的方法论。从古法编程到 AI Agent 开发的跃迁从来不是靠“换个工具”完成的而是靠你重新理解编程的对象从“逻辑”变成了“行为”。这个关一旦过了后面的事情会顺很多。