最近阅读了 Anthropic 发表于12月20号的一篇文章《Building effective agents》（https://www.anthropic.com/research/building-effective-agents），觉得挺有收获，遂做了些笔记分享一下。
LLM Agents（大模型智能体）已经成为LLM时代的一个热门方向，其受到人们的关注，主要有这么几点：
三个臭皮匠顶个诸葛亮，一个LLM不行，我多搞几个LLM合作一下可能就行了 scaling law for agents，就如 LLM 通过不断增加参数、数据，能出现能力的涌现现象一样，agents上了规模，可能也会有意想不到的惊喜 操作LLM主要靠prompt，还是得人来主导，agents可以当做有自主决策能力的单元，agents系统不需要人作为“中枢”了，它们自己进行规划和行动
说实话，由于我已经脱离学术界，所以基本没有读过什么agents的论文，只是偶尔通过一些博客、讲座进行跟进，一直以来对 agents 还是一知半解的，而且感觉大家谈论的agents有时候都不是一个东西。最近看到 Anthropic 的这篇文章，觉得它最棒的一点就是“清楚地告诉了我什么是Agents，什么时候该使用Agents”。
下面就是一个简要的总结：
分清楚 LLM Workflows 和 LLM Agents
这是我们经常搞混的概念，workflows 和 agents。二者的目的很不同，workflows是人来定义明确的规则和流程，然后中间步骤由LLM来执行；但是 agents 是为了更加灵活地处理某些任务，且决策是由模型决定的，而不是预定义的规则。
大多数的应用可能用不着 agents，优化prompt，使用RAG或者ICL技巧及足够了。
基础组件——增强的LLM
无论是 workflows 还是 agents，基础组件都是增强版的LLM：
单纯的LLM只有语言功能，但是增强版的LLM，拥有查询、调用工具以及记忆功能。所以可以看出，门槛还是很高的。当然，根据实际的场景，有些功能可能并不需要，这些功能的具备，只是为了保证基础的能力足够强大，才能帮我们可靠地完成一些复杂任务。
一些典型 workflows
Prompt-Chaining: 当任务可以被清晰地划分成多个steps。一般用于用更高的延迟，来换取更高的准确率。例
Routing：当需要考虑针对不同场景要采用不同模型时，可使用这种导航的workflow。
Parallelization：并行处理，当需要同时得到多个结果，最后集成在一起时使用。
Orchestrator-workers：这个跟上面的区别在于，使用一个模型来判断任务要怎么划分，你事先可能没有一个明确的子任务划分。
Evaluator-optimizer：迭代优化工作流。让LLM的结果不断自我优化。使用这种工作流，一般需要满足两点：1.LLM的输出，确实可能有很大的提升空间；2.LLM有能力对输出提供有价值的评价
可以看出，绝大多数的任务场景，上述的这些 workflows 基本可以覆盖了，这些场景，我们并不能称之为 agentic systems（智能体系统）。
真正的 Agents 系统：
真正的 agents 系统是为了解决：
复杂的开放性问题 难以对问题进行明确的分解、分步，难以规划
在这种场景下，让一堆agents自己去探索就非常合适，但同时，你必须对LLM有一定程度的信任。
例如一个经典场景：编程助手（不是单单代码补全，或者简单的代码问答，而是能直接操作一个工程）的内部流程可能是这样的：
注意到，agents系统这里多了一个“环境”，而agents需要自主决定跟环境的交互，具体的交互步骤是人无法事先固定好的。
Anthropic 根据上述流程，针对 SWE 任务搭建了一套agents系统，成功地刷新的SOTA，具体参见：https://www.anthropic.com/research/swe-bench-sonnet
Agents的落地
agents这么火，之前我一直感觉主要还是停留在paper阶段，落地的似乎还不多。最近去听了知名Agents开源框架 Camel.AI 的创始人李国豪的一个报告，会后我找他分享一下他们目前agents落地的最好的场景，他告诉我是“智能客服”。现在看到 Anthropic 的博客，它里面也提到了类似的场景。目前 Agents 落地最成功的两个场景就是：
客服系统 常规的QA功能 对接数据库，查询功能 修改用户数据 自动化票据生成 编程IDE 著名的Cursor编程IDE 例如 Anthropic自己对SWE-bench做的工具：https://www.anthropic.com/research/swe-bench-sonnet
总结/宝贵经验
Anthropic的工程经验：
大道至简，尽量维护系统的简洁； 尽量让过程更加透明（因为你依赖的是LLM的决策，如果只看输出不看过程，很容易陷入难以debug的情况）； 对LLM需要调用的工具，尽可能地好好进行工具说明和测试。
我觉得这三点，对于开发任何系统，都非常有指导意义。我们常常把简单的事情弄得复杂，却又在需要努力的地方偷懒。比如有意或无意地搞一个复杂的系统，把人绕的云里雾里，debug难度大，但实际上真正起作用的是一个很简单的东西；比如不愿意对一些细节进行调研、不愿意写文档写注释、不愿意对中间步骤做验证。。。对，我说的就是我自己，每次做一个项目，回过头来复盘的时候发现大量时间被浪费在当初以为无关紧要的而没有好好处理的细节上。
以上。
进技术交流群请添加AINLP小助手微信（id: ainlp2)
请备注具体方向+所用到的相关技术点 关于AINLP
AINLP 是一个有趣有AI的自然语言处理社区，专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。
