🪴 小胖的数字花园

Agent

6分钟阅读

Agent

单智能体= 大语言模型（LLM） + 观察（obs） + 思考（thought） + 行动（act） + 记忆（mem）
多智能体=智能体 + 环境 + SOP + 评审 + 通信 + 成本

多智能体优点：

  1. 多视角分析问题：虽然LLM可以扮演很多视角，但会随着system prompt或者前几轮的对话快速坍缩到某个具体的视角上；
  2. 复杂问题拆解：每个子agent负责解决特定领域的问题，降低对记忆和prompt长度的要求；
  3. 可操控性强：可以自主的选择需要的视角和人设；
  4. 开闭原则：通过增加子agent来扩展功能，新增功能无需修改之前的agent；
  5. （可能）更快的解决问题：解决单agent并发的问题；

缺点：

  1. 成本和耗时的增加；
  2. 交互更复杂、定制开发成本高；
  3. 简单的问题single Agent也能解决；

多智能体能解决的问题：

  1. 解决复杂问题；
  2. 生成多角色交互的剧情；

Multi-Agent并不是Agent框架的终态，Multi-Agent框架是当前有限的LLM能力背景下的产物，更多还是为了解决当前LLM的能力缺陷，通过LLM多次迭代、弥补一些显而易见的错误，不同框架间仍然存在着极高的学习和开发成本。随着LLM能力的提升，未来的Agent框架肯定会朝着更加的简单、易用的方向发展。

agent 友好的代码库

核心问题是：如果把一个 Agent 放进你的代码库，它能理解正在发生什么吗？

Agent 友好型代码库的核心原则

1. 测试是合约

Agent 靠什么确认自己没有搞坏东西？靠测试。

核心观点：

  • 测试是定义软件正确性的合约
  • 测试覆盖不够 = 没有给 Agent 立规矩
  • Agent 只能基于显式定义的合约来运作

实践要求：

  • 80%+ 测试覆盖率（硬性要求，不是建议）
  • 测试先于功能实现（TDD）
  • 测试要覆盖边界条件和错误场景

2. README 和代码必须一致

代码说一回事，README 说另一回事 → Agent 会犯迷糊。

核心观点：

  • README 和代码脱节是常见问题
  • Agent 读到互相矛盾的描述时不知道该听谁的
  • Agent 快速复合错误：第一步误解 → 在错误基础上加倍错下去 → 意面代码（spaghetti code）

实践要求：

  • README 是代码的真实反映
  • 代码更新时同步更新文档
  • 示例代码必须可运行

3. 设计模式要一致

如果代码库中用两种不同的方式做同一件事，Agent 不知道该选哪个。

核心观点：

  • 同一种对象应该用同一种 API 创建
  • 设计模式不一致 → Agent（和人类）都会困惑
  • “如果我走进你的代码库看到两种不同的做法，我也会问：该用哪个？”

实践要求：

  • 统一的代码风格
  • 统一的架构模式
  • 统一的命名约定
  • 统一的错误处理方式

4. 代码库本身要搞对

在你让 Agent 写代码之前，先把代码库本身搞对。

核心观点：

  • Agent 看到的第一版代码必须是自洽的
  • 设计完善
  • 测试充分

实践要求：

  • 代码审查不能只看 Agent 写的新代码
  • 要看整体代码库的一致性
  • 重构比新功能更重要

Agent 友好的代码库，其实就是对人也友好的代码库。

好的工程实践没有变，只是在 Agent 时代变成了硬性要求，而不是”最好这么做”的建议。

参考资料

课程

关系图谱

反向链接