面试官抛来一个模拟客服需求：“拿到订单号，查询物流，把状态解释给用户。你准备用什么？”
我第一反应是上 Agent 框架，把查询和回答拆成两个节点。
他反问：“一个函数调接口、再调模型，哪里不够？”
我差点脱口而出“方便以后扩展”。这话很安全——因为“以后”什么时候来、要扩展什么，我一个字都没提。
一、先把两道选型题分开
这类讨论常常把两个问题搅在一起：任务到底需不需要模型动态选择下一步？实现时到底需不需要框架提供运行能力？
它们其实是两码事。
固定流程完全可以调用模型，用来理解自然语言、整理回复。可用了模型，不等于整个流程都交给模型说了算。反过来，一个根据工具反馈继续行动的 Agent，也完全可以先用普通代码实现，并不天生依赖某个框架。
回到当前需求。订单号是明确的，查询入口也固定，拿到状态就作答。这条短链路，我倾向先用直接调用——把成功、查不到、服务失败这几种分支都写清楚。
这不是否定框架的价值，而是眼下还没找到值得承担额外依赖和学习成本的理由。
二、需求变复杂，要说清复杂在哪里
面试官加码了：“用户只说东西没到，没给订单号。”
这时候可以先澄清，也可以在授权范围内列出待确认的订单，让用户自己选。如果产品规则早就写死了这一步，它照样能走固定流程。
再加一码：“查到还没发货，要看商家的处理状态；已经发货了，又得结合不同物流来源判断缺什么证据。”
只有当下一步高度依赖中间信息、路径又很难提前写死时，才有理由让模型参与选择——查询、补问，还是停下。它负责的是适应变化，而不是把所有 if 都翻译成提示词。
用户说“先别催单”，执行层就必须限制写操作。查到未知原因，也不能让模型现编一个，好让流程看起来顺利收尾。
我会先证明动态决策确实改善了任务结果，再去讨论这个过程怎么跑起来才稳。
三、框架的价值，常出现在演示之后
“客服把工单草稿整理好了，要等用户明天补一张图片。服务今晚要重启，明天接着办，怎么办？”
到这儿，问题已经超出几个条件分支。我得保存任务状态，得知道等什么、从哪儿恢复，还得区分哪些步骤已完成、哪些动作不能重复执行。
比如 LangGraph 提供了状态编排、检查点和中断恢复这些能力。它能承接一部分通用的运行机制，但前提是选好持久化存储并正确接入——别以为上了框架，重启就自动不丢任务。
更不能把检查点当业务事务用。假设工单已经创建成功，状态还没保存进程就退出了，恢复时照样得避免重复创建。业务接口的幂等与结果核对，不会因为你画了个图就自动冒出来。
我会用这类故障场景来验证框架的收益：停在等待状态重启后，任务能不能正确恢复；恢复期间会不会重复执行有副作用的操作；日志能不能解释清楚当前到底卡在哪。
同样的运行需求，普通服务、数据库加工作流系统也能解决。框架只是候选实现之一，不能因为需求里冒出一个“等待”，就宣布只有某个库能扛。
四、怎么证明引入它是划算的
我会挑一条有代表性的客服链路，分别看直接实现和候选框架各自要维护哪些代码。比较点紧扣实际需求：状态恢复、错误定位、改动范围，以及团队能不能看懂执行过程。
不能只比 Demo 代码的行数。框架确实把细节藏了起来，能减少重复劳动；但升级兼容、序列化限制和排障路径，也会变成新的维护负担。
“那不一开始就用，以后切换不是更难？”
所以我会先把模型调用、订单服务和业务状态的边界拆开。业务规则放进可以独立验证的代码里，别散落在框架回调中。之后换不换编排方式，都不用重新解释退款或催单的规则。
设计得清楚，比抢着装上一套最完整的框架更能压住迁移成本。当然，如果团队已经有成熟的运行平台，沿用现有能力也可能比另起炉灶更省事。
面试时，我会这样回答：
“我会先分清两件事：任务是否需要动态决策，实现是否需要框架。短而固定的流程，直接调接口和模型就够了；需要根据反馈调整路径时，再引入受约束的 Agent 循环。框架划不划算，要看它能不能减少状态持久化、暂停恢复、追踪这些实际维护成本，同时评估依赖和调试负担。无论怎么选，业务权限、幂等和完成条件都不能交给框架名称来保证。”
这是《Agent 开发面试全解》第 04 篇，基础与选型模块到此收口。下一模块会从最小 Agent Loop 开始，把前面聊的那些职责真正落到代码里。更多 Agent 开发相关讨论，可以到 云栈社区 看看。
发表于 2 小时前
|
查看: 2|
回复: 0
