Agent开发问题

约 1296 个字 预计阅读时间 4 分钟

1.调通API

你可以安装SDK写几行代码，把用户输入丢给大模型，拿到返回结果。如果是OpenAI的API，直接使用Cursor等工具，用自然语言描述需求，就能把脚手架搭好，然后你可以自定义几个tool，把JSON schema写好，模型就能调用了。

2.接真实API

Demo里用的是mock数据，现在得接真实数据了。

第一个问题是OAuth。

然后是API的各种边界情况。

API的速率限制也是个问题。如果你的Agent在一个复杂任务里连续调用十几次，很容易触发429（too many requests）。

接入API只是tool call的一般，tool本身怎么设计，tool schema和tool call result怎么写，这个问题不是那么容易的。Berkeley的Function-Calling测试发现，模型面对的工具数量越多、参数越复杂，调用准确率下降得越厉害。tool的粒度太细用户需求cover不住，太粗模型又hold不住，这个平衡点没有标准答案，只能在具体场景中反复测试。

tool的description也很关键，或者说是最为关键的，这是给模型调用工具的说明书。

生产级Agent系统中AI只完成了30%的工作，剩余70%是工具工程。

3.多步骤任务

当面对一个多步骤的复杂任务时，Agent可能会有灾难式的表现。

Berkeley的Function-Calling排行榜显示，最好的模型工具调用准确率也只有77.5%。这意味着每4次调用就有近1次出错。一个五步任务全部正确的概率？大概是0.775的5次方，不到28%。你的Agent有超过70%的概率在某一步翻车。

更麻烦的是Galileo的研究发现的问题：早期的一个小错误会在后续步骤中不断放大。 假设第一步查日历时模型解析时间格式出了个小bug，把周二理解成了周三，后面所有步骤都在错误的基础上继续。它会在一个不对的时间段创建会议，发给所有人一封时间错误的邮件通知。一个小幻觉触发了一连串错误操作。

这时候你开始意识到，你需要在每一步之间加校验逻辑、加回滚机制、加确认环节。而这些东西，没有任何一个LLM的API文档会教你

4.成本问题

对于简单请求，我们的想法是用简单模型，而对于复杂任务，应该用高级模型。不同的任务用不同的底座模型，这个思路很自然，但实现起来是一个很大的工程挑战。

你需要一套任务路由机制：先判断用户意图的复杂度，简单查询走便宜的小模型，复杂的多步骤推理才走大模型。但是这个复杂度谁来判断？又如何判断？

而且不同模型的tool call能力不同，tool schema也不适配，每换一个模型，之前精心调试的prompt和tool description可能都得重新调整。

5.上下文管理

为了解决Agent遗忘的问题你需要进行上下文工程，说白了就是LLM版的“内存管理”：你得动态决定每一步推理时模型能“看到”什么、该“忘掉”什么。

还有一个坑：研究发现上下文长度和幻觉率正相关。

6.测试

OK，现在Agent勉强能用了，那么如何确定它的效果呢？

传统软件开发有成熟的测试方法论：单元测试、集成测试、端到端测试，输入是确定的，预期输出也是确定的。但Agent的输入空间是开放的（用户可以说任何话），输出也是不确定的（模型每次生成的文本都不同）。LangChain的博客一针见血："每一个输入都是边界情况"，这是传统软件从未面对过的挑战。

而且实验室测试和生产环境之间可能差距甚大。

7.多Agent

多Agent之间如何沟通？如何分工？这些问题可不是那么简单。多Agent并不一定优于单Agent。

8.瓶颈

底层大模型是Agent能力的瓶颈，当上述步骤都解决后，Agent的上限来自于底层大模型的能力。

9.框架选择

框架只是工具，不是必需，Langchain，CrewAI等常常使底层prompt和响应变得不透明，增加调试难度。重点在于前面的工程思路。

10.总结

Agent与Agent之间的巨大差距，根源不在谁调的接口不同，而在接口之外的工程做得天差地别。 调接口是入门门槛，一周就能跨过去。但从Demo到产品，中间隔着的是一整套关于可靠性、可观测性、上下文管理和错误恢复的系统工程。这才是Agent开发真正难的地方。

11.Reference

agent与agent之间的差距很大，但agent开发不就是调接口吗？agent开发的难点是什么呢？