从调模型到系统工程
在当前这个时间点，AI agent大行其道，在这个龙虾到处杀职业的时间点上，几乎所有人，都在开始参与AI。
其实开发AI应用很简单：前后端的系统的逻辑中，在某些环节上加一些模型调用即可（意图、结果、分支）。用你的后端语言，写上提示词，对接模型API（框架都不用），向前端返回一个sse的接口，一个AI应用完成了。
但是上线后，你会发现很多问题：用户的问题，可能与你业务上定义的系统提示词不一样而胡乱回答；数据库可能死锁；返回的内容可能错误；工具可能调不出来，等等…
正如前端开发不是写html, css、写ref和reactive一样，用一用langchain，构建两个tool，其实也与ai 应用开发相差甚远。软件开发是一个系统工程；AI应用开发，也应该是一个系统工程。前后端有工程化，那AI Agent也应该有工程化。
AI 应用系统的复杂性来源
所有的工程化，都是为了解决将技术应用于现实解决问题时所遇到的一系列问题。而将大模型应用于现实世界，所遇到的问题，与常见的软件工程的问题还不太一样。
模型本身就是不确定性的来源
很遗憾的是，agent系统的核心大模型本身就是不确定的；模型输出基于概率，与传统软件的确定性输入输出完全不同。
同一个模型，同样的提示词，两次输入得到的结果不一样；改了模型，改了温度，结果更不一样；不同模型可能输入输出的结构不一样；不同模型训练时的方式不一样，对不同的指令敏感度还不一样。
再涉及工具调用的稳定性，错误重试等。
于是，有时候调试提示词本身就变得像一个艺术或者是碰运气，你永远不知道哪个关键词会使模型输出你想要的结果。
如果在特定的业务场景下，老板又要需要一些特定输出（他并不知道或者不能接受结果是有概率的），你只能不断的加特定指令。至于生不生效，那只有天知道。
上下文状态的复杂性
传统软件系统的状态有几个层级，前端的交互状态到后端系统的状态，但总的来说，这么多年以来几乎已经有了很多的经验来解决。基本上，传统后端接口大多仍然是无状态API。
但AI 系统本质是加入了模型来作为状态处理和决策的软件系统，状态会更加复杂，传统状态机的那些机制无法控制它们。每个session都可能包含：
- 记忆，长的短的工作的，包含消息队列等会话状态等等，如何以及在什么时机召回、插入什么地方
- 任务状态。任务编排，工具状态，重试计数等等
还有这些状态如何保存以及在适当的时候召回；断线后要不要以及能不能重新找回；状态避免污染 和保持一致性等等都是一系列新的挑战。
可观测性
AI系统的可观测性很容易被忽略（可能是因为工程化体系还不完善），再加上系统复杂性本来就高，上线后出问题有时候难以定位到底是模型、还是数据，还是其他地方的问题。
同时由于模型本身的不确定，bug复现也极难，如何定位、复现问题？
这又会涉及：
- 能不能做，怎么做全链路的追踪，状态的流转，决策的跟踪
- 怎么模型调用做观测，每次的输入输出、延迟、cost等等
- 线上幻觉率、成功率如何在检测和统计等等
Agent模式的复杂性
系统提示词+问题调模型，接收回复，这是最简单的ai应用方式。但业务一旦复杂起来，就必然会有：
- 路由，根据情况或问题来分成不同的模型或者提示词处理
- RAG，如何自动来获得相关的信息，放在哪一步又如何混入提示词（这都还没考虑召回的问题）
- ReAct，让模型不断诊断自己的状态，但如何控制步数，如何让问题收敛，失败了怎么做？
- ToolAgent，工具如何抽象（在业务场景下这很重要），工具要不要做权限分级，等等
- multi agent, skills and so on….
模型可能在复杂的任务循环或者乱跑，难以收敛，规划的有效性与稳定问题；多个agent或者模型间的协作问题；任务的拆解的有效性，等等。
数据与知识工程
如何维护一个知识体系本身就是一个难题。
- 数据本身的更新与维护的机制，还得分结构化与非结构，说不定还得引入大数据的体系
- 索引与召回的策略。引用和追溯。
- 数据权限如何做
评估
传统软件是输入输出的确定性状态机。 但agent系统是无限输入和无限输出的状态机，测试难度不可同日而语。
提示词中改一个标点符号可能都会让输出与原来不同；而用户的输出更是无法预测。
如何保证修改提示词、调整模型以后的业务目标稳定性，又是一大挑战。
安全与合规
提示词可能会被用户恶意注入或利用，导致极大的安全问题；提供给模型的上下文可能包含敏感的信息，在测试的时候往往又难以显现。
保证Agent系统的安全，又是一大难题。
服务工程问题
Agent系统也是软件系统。尤其是BS/CS架构的，传统服务端的一些问题也会在这里出现并且放大，而且在某些领域还会更加复杂。
- 长连接问题。普通rest接口可能1秒都算高的。agent接口一次回复可能几十秒甚致几分钟。如果是research模式的agent运行，时间会更长。运行时间一长，复杂度进一步上升。同时还要涉及与前端的信令协议（如果要交互好的话）
- 可靠性和容错。tool调用可能发生多次，冥等性如何做；中间状态多，超时如何处理，要不要做降级处理等问题；
- 并发。agent系统也会有并发问题，而且，有时候会涉及到上游模型的速率限制，如何做排队、限流等等
- 分布式。如果与外部系统交互，那又会涉及分布式事务等传统分布式遇到的问题。
- 容量与伸缩。如果上线了，用户量一大，模型用量、并发量更加复杂。资源如何优化？
- 缓存策略。搜索服务奇贵，如何省成本？又涉及语义/结果缓存等等
版本管理
改东西会不会变差？会不会影响？跟常规系统的版本管理、发布管理一样，agent系统也得处理这些。
- 版本管理。各个部分，prompt，工具，数据，能不能回退和追溯？
- 发布管理。要不要搞个灰度或者AB？
以上，都是我在开发AI应用过程中，遇到或者了解到的问题，有些已经解决，而有些暂时还在搁置。传统软件系统的工程化，发展了多年才逐步有一些系统性的解决方案。
我想，agent系统，也许是新的物种，也会发展很多年才会逐步形成系统性的解决方案来解决它们。
