以下内容整理自 YouTube 视频 那些 Agent 神文没告诉你的事：照着做，系统只会更烂，由 Gemini 协助总结，并经过细微修改。

1. 架构设计的“反直觉”：别在不确定性上叠加复杂性

在传统软件开发中，先设计好完美的架构是美德。但在 AI 领域，这可能是一个巨大的陷阱。

  • API 优先原则：如果一个任务（如写个标题、总结文章）能通过一次 API Call 解决，千万不要用 Agent。
  • Workflow vs. Agent：如果任务步骤是固定的，且不需要用户中途参与（如自动视频剪辑流），请使用 Workflow（工作流）。只有当流程需要人的偏好介入，或者功能多到前端 UI 放不下时，才需要对话式 Agent。
  • 反向叠加：AI 本身就是非确定性的系统，在它上面搭一层精致的架构，等于是在不确定性上叠加了另一层不确定性。

2. 演进逻辑：Agent 是“被逼着”长大的

完美的架构不是设计出来的，而是根据需求一步步演化出来的：

  1. Baseline 第一：不要一上来就用 LangGraph 等重型框架。先用最基础的 SDK 跑通核心逻辑，知道任务的 baseline 在哪。
  2. Prompt 由简入繁：不要一上来就写万字说明书。先给简单的指令，看它在哪里出错，再针对性地添加限制条件或示例（Few-shot）。
  3. 能力不足再加工具：当 Prompt 无法解决问题时（比如它需要搜索实时信息），再引入 Tool。你会发现每加一个工具，Agent 都会变聪明一点，这才是真正的“涌现”。

3. 高阶优化：上下文工程与记忆系统

当你的 Agent 开始变得复杂，你会遇到性能持续下降的问题。这时才需要引入大厂文里的“高级货”：

  • 上下文隔离（Context Engineering）：如果让 Agent 同时处理设计和写代码，上下文会互相干扰。通过 Sub-agent 架构，让不同角色只看到自己需要的那一小撮信息。
  • 内存 vs 外存：
    • 内存：这轮对话结束就消失。
    • 外存：跨轮次保存的状态（如 Todo List），防止 Agent 迷失方向。
  • 传“指针”不传内容：在不同 Agent 之间传递长代码或大数据时，不要让它反复读写（烧 Token 且易出错），而是通过文件系统传递路径或引用。

4. 调试：过程比结果更重要

对于长任务 Agent，如果它失败了，你必须知道它死在哪一步。

不要只存结果，要存全过程：工具调用的顺序、每步消耗的 Token、哪些上下文被浪费了。只有回头读流程，你才知道如何把任务规划得更快、更省钱。

总结：不要让“优雅”成为绊脚石

那些大厂的“毕设级”架构图确实精妙，但它们是经过无数次实验后的终点，而不是你开发的第一步。

不要一上来就追求架构的优雅。先跑起来，让需求推着系统去进化。