么是agent、为什么要做agent、怎么做agent、怎么工程化

什么是agent、为什么要做agent、怎么做agent、怎么工程化

什么是agent

从第一性原理角度出发，没有agent的时候，软件工程是怎么做的。通过代码来实现系统的控制流，if/else、for循环、状态机等。这些都是基于规则驱动的，系统的执行路径在写下代码的时候就已经锁死了（硬编码）。因此，为了方便后期的修改，就有了面向对象编程，架构设计等。而现在，人们发现llm本身可以做判断、生成和调用外部工具的能力。因此，我认为agent的本质，是将系统的控制流决策权，在运行期间部分或者全部移交给了llm。即由模型根据当前环境反馈，自己决定下一步调什么工具、循环几次、什么时候停下来。

这个概念可以从很多角度去理解，我很喜欢的一种理解是滚雪球：

agent就像是一个下山滚动的雪球，初始的提示词会规划它的方向，而每一次的滚动都会形成轨迹，从而影响下一次的滚动。

这种理解天然可以解释一种观点，那就是agent的能力取决于人使用的能力（引导能力），它很难会在最开始纠正你的非错误方向，以给出最优途径。比如，你让他去做一件事情，但实际上这件事有一种更简单的实现方式，但是agent不会主动提出，而是根据你指定的路径往下滚。因此，人的引导和认知对齐对于agent的上下文是至关重要的。做agent有一个很重要的点，是要理解agent能做什么，以及agent会怎么做。

另外，agent的概念经常会与workflow混淆，其实区分的角度很多种，刚刚我们提到llm可以做判断、生成的工作，一种不是那么对但是在大多数场景下：workflow往往是判断的工作，而agent则会有生成的工作。直观的一种体现是，当外部环境返回非预期结果（如工具调用报错）时，系统是直接抛出异常终止，还是能由模型自主理解错误、修正参数并发起下一次尝试。

基于上述的解释，很容易产生一个问题：

为什么要做agent

目前，在大多数业务场景，大家通常都会优先选择workflow。理由很简单，workflow相较agent更为可控，同时把llm作为其中的一个模块，开发的难度会简单很多（至少在很多场景，我会选择先从一个workflow做起，然后验证，最后把它组装成agent，或者干脆就把它作为一个功能模块）

那为什么还要做agent，我认为有这么几个理由：

agent能力强于workflow。在一些真实业务场景，如智能客服，用户的意图与环境状态存在无数种长尾组合，如果用workflow去穷举所有分支，代码维护成本会指数级上升。这时候，我们发现agent可以利用本身的涌现能力，通过一段提示词，完成原本复杂的判断逻辑。
用环境反馈去对冲潜在的模型幻觉。一个很常见的错误观点是，假设一个llm单步生成准确性在80%，那么在多轮对话后，它的准确率会越来越低。而实际上恰恰相反，随着多轮迭代后，模型准确率反而可能上升了。这是因为有react这种agent设计，引入了行动act-观察observe-修正reflect的结构。比如，生成一个SQL，agent第一次生成错了没关系，会看到真实的报错信息，然后重写。本质上，用多步迭代的方式，换取超越模型原始基线的高可能性。
ai native。这是我最近感触到的。llm正在快速发展、迭代，模型的能力越来越强，现在llm做不到的不意味着以后也做不到。以前业务场景会写很多胶水代码or硬编码的逻辑，在ai用方面则是几千行繁琐的提示词、few-shot。结果随着llm发展，这些代码不仅没用，反而还限制了架构进一步优化和模型发挥。所以，很多时候，大家又把agent叫成harness，马鞍。我们会把更多的注意力放在给llm打造一副好马鞍上（更好的工具、sandbox、更好的上下文）。因此，现在很多架构设计要求ai native，即当底层llm模型升级后，业务效果能否进一步提升，而不需要重构代码。

当然，agent不是万能的，一个好的agent背后需要大量的设计与思考，而不是vibe的demo。

怎么做agent

首先，先做顶层设计，了解整体框架，了解业务约束，了解你要干什么，不要过度设计。计算机更多是一门应用学科（技术），而不是纯科学。这一步很难，因为这意味着你需要在背景知识最少的时候，去做影响最大的决策（架构设计）。**这一步我的建议是，多写文档，将自己的认知、假设、判断依据显性化。**因为，随着项目推进，不可避免地会根据遇到的问题，反复优化你的决策（就像贝叶斯概率那样）。

其次，站在巨人的肩膀上看世界，先调研。这个是一个通用的经验和习惯，我发现很多人没有意识到，尤其是现在ai的发展，deep research和复现是一个很容易实现的事情。不要上来自己手搓轮子，没有意义。

完成上面两个步骤后，开始我们的问题，怎么做agent，可以从这个公式出发：

agent = LLM + 记忆 + 工具 + 规划

这里的规划很多时候可以理解成agent设计模式，如react、plan-execute等。

这里，我们重点关注规划和上下文（记忆模块）。

设计一个可用的agent核心在于控制自由度和上下文。不同场景选择不同的设计模式和上下文管理：

客服场景等强规范场景，通常用路由工作流（routing+workflow），意图识别-抽槽-澄清-workflow，缺点在于灵活性受限（llm的生成能力在于意图的生成上面，其实也可以说是为了将多个workflow组织起来，加一个意图识别）；

那在这种场景中，上下文的设计核心在于前置私有信息的注入与槽位状态管理。如客户静态背景画像、rag检索用的业务知识库、以及当前对话提取到的结构化槽位结果。这里需要分清一些概念，**上下文有时候和记忆是同一件事，但是强调的侧重点不同。上下文更加强调运行时候llm得到的信息以及上下文状态的管理，而记忆则是强调llm需要输入输出哪些信息，这些信息本身是怎么存储的。**另外，记忆不等同于rag，rag是实现长期记忆的一种方法（并非唯一，如faq）。
deep research、逆向工程等，则需要更多ai自己去探索，那么通常会选择plan-execute架构（我比较喜欢的架构），deerflow、artex都是用这种架构的，plan生成全局DAG计划，然后执行模型依次执行；
数学研究等复杂场景，则用multi-agent（多智能体协作），需要多视角博弈或上下文隔离的场景。当一个任务需要大量的上下文背景时，如果全塞给一个agent，上下文很快就会爆掉，导致模型降智、出幻觉。这时候就需要一个主agent去分解任务，然后让子agent去干活，然后把结论返回给主agent。本质上是再用空间换信噪比。

deep research和multi-agent之间并不互斥，可以相互兼容。记忆模块目前也没有什么标准解法，根据业务场景去推我们需要哪种设计模式和记忆，而不是根据技术来反过来适应业务。**这里又要聊到第一性原理了，有时候看一个agent框架，不要先看他怎么做的，而是想想在这个场景下，agent需要哪些记忆（多agent上下文怎么管理）。**作为算法工程师，我很喜欢去抓设计的本质，代码和模块只是最终的实现手段。记忆的存储方式又有很多种，向量化or直接存数据库，或者用一些数据结构如图结构表。本质上，只要agent在需要的时候可以快速找到就可以了。

工具的话，有一个点，现在很多人喜欢直接把原有后端的restful api包装给tool扔给模型，发现效果很差，归根结底是因为没有写给模型看到feedback。llm调用tool，返回一个404，模型只好再去调用，失败了它也不知道怎么办。有时候直接返回模型的入参就行了，如，错误：字段xx不存在，当前可用字段为xx、xx，请修正重试。tool是写给概率模型看到，收拢颗粒度，根据业务语义提前聚合成一个高内聚的tool，防止ai细碎地调用，给出ai看得懂的feedback。这个可以看anthropic写的ACI概念。

怎么工程化

为什么会单独强调工程化，是因为现在agent很容易做成一个demo，但是很难真正应用在生产环境中。工程化会遇到一些可能非模型本身的问题，如延迟、token消耗、线上死循环等。因此要在生产上可用，工作的重点在于非确定性治理。用确定性的软件工程手段（状态机、类型系统、沙箱、上下文裁剪、回归评测），把大模型的不确定性关进最小的笼子里，只在最需要动态推理的那个节点上释放它的泛化能力。

这里是一些方法论：

事前和事中的确定性护栏（写好schema约束）：相信ai，但是保持怀疑。首先，所有路由判断和工具入参，做好json规则检验，如果格式不对直接打回；其次，限制最大循环步数和时间，防止llm反复调用一个相同的工具（这个挺常见的，有时候工具调用成功了，但是执行需要时间，最后先传回一个信息，防止llm以为没读取到而反复读）；
沙箱隔离与异步挂起与恢复：一些场景做好沙箱隔离；设计一个护栏，根据关键词等进行监测，如果触发则转人工确认。
构建评测集：独立的闭环评测（单元测试）、轨迹评测（过程测试）、端到端评测（结果测试）。
trace采集与故障归因：用langfuse，首先我们要得到信息，我们才能分析。然后就是做好bad case、hard sample的分析。
构建数据飞轮：把上面的结果沉淀成知识，从而迭代提示词、skills。

工程化更多是经验，很多东西不踩坑，是根本意识不到，这个我目前也没有很深的理解，没有形成整体的设计原则，只能根据一些要点去排查。但真实业务场景远比这个复杂的多，会有很多奇奇怪怪意想不到的问题（可能这就是ai无法完全代替人的点之一吧）。