# AI Agents: The Complete Course
**作者**: Rahul
**日期**: 2026-05-24T08:25:37.000Z
**来源**: [https://x.com/sairahul1/status/2058464422306443766](https://x.com/sairahul1/status/2058464422306443766)
---
Everyone is talking about AI agents in 2026.
Most people have no idea how they actually work.
This changes today.
I spent weeks distilling everything: courses, books, real builds, production failures.
Here's what you actually need to know.
Whether you're automating your own workflow or building production AI systems for a company — this is your roadmap.
Save this. It's long. It's worth it.
## PART 1: BEGINNER What AI agents actually are
## 1. What is an AI Agent?
A regular LLM does one thing:
You ask. It answers. Done.
One shot. Linear. No iteration.
An AI agent works differently.
It works the way you actually work on hard tasks:
→ Plan first → Research → Draft → Review its own work → Revise → Repeat
This is called the ReAct loop:
Reason → Act → Observe → Repeat
The model reasons about what to do next. Acts (usually by calling a tool). Observes the result. Then either gives you the answer or loops back.
Why does this matter?
Each pass adds depth. Stronger reasoning. Fewer hallucinations. Better organization.
Everything you lose when you try to do it in one shot — agents get back.
## 2. What are Agents Actually Good For?
Not every task needs an agent.
The right mental model: a 2×2 matrix.
Axes: Complexity vs Precision needed.
→ Low complexity + high precision = just use code → Low complexity + low precision = just use a single LLM prompt → High complexity + high precision = agents with heavy guardrails (tax forms, legal docs) → High complexity + low precision = sweet spot to start
That last quadrant is your fastest early win.
Examples of perfect agent tasks:
→ Research and write a report
→ Respond to customer emails (look up order → draft reply)
→ Process invoices
→ save to database
→ Answer "Do you have blue jeans under $80?" by actually checking inventory
Agents shine when the task needs:
→ Multiple steps
→ External information
→ Iteration and self-correction
If you can solve it with one prompt — don't build an agent.
## 3. The Autonomy Spectrum
The first big decision when building an agent:
How much control do you give it?
Think of a spectrum.
Scripted (left end)
You hard-code every step.
→ Generate search terms
→ call web search
→ fetch pages
→ write essay.
The model just does text generation. You decide everything else. Predictable. Easy to debug. Limited.
Semi-Autonomous (middle)The agent picks from tools you defined. Makes decisions inside guardrails you set. This is where most real production systems live.
Fully Autonomous (right end)The LLM decides everything. What to search. How many pages to fetch. Whether to reflect. Whether to write new code and run it. More powerful. Much harder to control.
Where should you start?
Middle of the spectrum. Give it tools. Set guardrails. Add autonomy only as you gain confidence.
## 4. Context Engineering
Here's what actually makes an agent "intelligent."
It's not the model alone.
It's the context you build around it.
Context engineering = deciding what information the agent has at every moment.
This includes:
→ Background — what is the task, who is the user
→ Role — "you are a research agent specialized in market analysis"
→ Memory — what has happened in previous steps
→ Available tools — what functions can it call
→ Knowledge — documents, databases, PDFs it can reference
Engineer this well → the model behaves consistently.
Engineer it poorly → unpredictable garbage.
The model is the same either way.
Context is what separates a great agent from a broken one.
## 5. Task Decomposition
The most important skill in building agents.
Start with: how would a human do this task?
Then for each step ask: can an LLM do this? A bit of code? An API call?
If the answer is no → split it smaller until it is.
Example — essay-writing agent:
1. Outline → LLM generates structure
2. Search terms → LLM generates, then calls search API
3. Fetch pages → Tool call
4. Write draft → LLM using fetched sources
5. Self-critique → LLM lists gaps and weaknesses
6. Revise → LLM rewrites based on critique
Each step is: → Small → Checkable → Has a clear input and output
When the final output is bad, you know exactly which step to fix.
This is the superpower of decomposition.
## PART 2: INTERMEDIATE Building multi-agent systems that actually work
## 6. Evaluation (The Boring Thing That Separates Pros from Hobbyists)
Nobody wants to talk about evals.
Everyone who ships real systems does.
How do you measure if your agent is working?
Simple tasks → count correct answers. Did the customer service bot answer the inventory question right? Yes/no.
Complex tasks → use an LLM as judge. Have a second model rate the output 1–5 using a fixed rubric. Did the essay have strong arguments? Proper citations? Right tone?
Two levels of evaluation you need:
→ Component-level — is each individual step working? (Are the search queries specific enough? Is the critique passing real feedback?)
→ End-to-end — is the final output good? (Is the essay actually good?)
If end-to-end fails but component evals pass → handoff problem. If a specific component fails → that agent needs work.
Start evaluating from day one. Don't wait for a "perfect" eval system. Ship something fast and iterate.
## 7. Memory and Knowledge
Two very different things that people confuse.
Memory = dynamic. Updates each run.
→ Short-term: the agent writes notes as it works. Other agents can read those notes. → Long-term: after a task, the agent reflects. What went well? What didn't? Stores lessons.
Next run → loads those lessons → applies them.
This is how you "train" agents without fine-tuning. Give feedback → agent improves over each run.
Knowledge = static. Loaded up front.
→ PDFs, CSVs, internal docs, database access → The agent's reference library → Give it once. It pulls from it whenever needed for accurate answers.
Think of it this way:
Memory = what you learned from experience. Knowledge = the textbooks you can reference.
Both matter. Neither replaces the other.
## 8. Guardrails
A working agent is not a safe agent.
LLMs are non-deterministic.
They can get the format wrong, state a false fact, go off-task.
Guardrails are the quality gate between "agent says it's done" and "task is actually finalized."
Three types:
Type 1 — Code checks (fast + cheap)Use for deterministic things. → Is the output the right format? Right length? Required fields present? Write a simple validation function. Run it instantly. Always prefer this when possible.
Type 2 — LLM judgeUse for nuanced quality checks. → "Is this response factually consistent with the source documents?" → "Is the tone professional and positive?" If the judge says no → explains why → agent revises → tries again.
Type 3 — Human in the loopUse for high-stakes decisions. Agent stops before finalizing. Sends output for human review. Human approves, rejects, or requests changes.
Most production systems use at least two of these three.
9. The 4 Design Patterns That Boost Every Agent
These four patterns reliably make agents better.
Pattern 1: Reflection
Don't stop at the first draft.
Model produces output → critiques it → rewrites based on critique.
Email v1: "Hey, let's meet next month. Thanks." Critique: vague date, no sign-off, tone too casual. Email v2: "Hi Alex, let's meet Jan 5–7. Let me know what works. Best, Sai."
Gets even more powerful with code — write it, run it, capture errors, feed back, model fixes.
Use for: structured outputs, long-form writing, code, procedural steps.
Pattern 2: Tool Use
Give the LLM a menu of functions it can call.
The model decides when and which tool to use.
Web search. Database query. Code execution. Calendar. Email. API calls.
LLMs can't do any of these alone. Tools are how agents interact with the world.
Pattern 3: Planning
Instead of a fixed pipeline, let the agent decide the steps.
Give it a toolkit. Prompt it to make a plan. Execute step by step.
Retail example: "Any round sunglasses under $100?" Agent plans: search descriptions → check inventory → filter by price → answer.
You didn't script those exact steps. The agent chose them.
Pattern 4: Multi-Agent Collaboration
Split complex work across specialized agents.
Researcher → Designer → Writer.
Each agent is great at its specific job. Output is better because no single agent is trying to do everything.
## 10. Multi-Agent System Design
How do you actually structure a multi-agent system?
Four coordination patterns, simplest to most complex.
Pattern 1: SequentialEach agent finishes → passes output to next agent. Like an assembly line. Researcher → Designer → Writer → Done. Easy to debug. Predictable. Start here.
Pattern 2: ParallelRun independent agents simultaneously. Researcher + Designer work at the same time. Writer combines their outputs. Faster. More coordination complexity.
Pattern 3: Manager HierarchyOne manager agent coordinates specialists. Manager plans, delegates, reviews. Specialists report back to manager, not each other. Most common pattern in real production systems today.
Pattern 4: All-to-AllAny agent can message any other agent. Chaotic. Hard to predict. Only for creative/low-stakes work where variation is okay. Don't use in production.
Rule of thumb: start Sequential. Add complexity only when you need it.
## PART 3: PRODUCTION What actually gets you from prototype to shipped
## 11. Advanced Task Decomposition
In complex multi-agent systems, how you decompose matters a lot.
4 patterns:
Functional — split by technical domain. Frontend agent. Backend agent. Database agent. Classic for engineering teams.
Spatial — split by file or directory structure. Agent 1 handles /services/users/. Agent 2 handles /services/orders/. Great for large codebases. Minimizes conflicts.
Temporal — split by sequential phases. Phase 1: Research. Phase 2: Plan. Phase 3: Build. Phase 4: Launch. Each phase finishes before the next starts.
Data-driven — split by data partitions. Agent 1 processes Week 1 logs. Agent 2 processes Week 2. Etc. Powerful for large datasets. Parallelize analysis.
You can mix these.
Functional decomposition for the main structure + temporal decomposition inside each agent.
Use whatever matches your task's natural boundaries.
## 12. Improving Quality in Production
System is working but not good enough.
Two types of components. Two different fix strategies.
Non-LLM components (web search, RAG, OCR, code execution):
→ Tune the knobs: search date ranges, top-k results, chunk size, similarity thresholds → Swap providers: try different search APIs, vision models, parsers
LLM components (generation, reasoning, extraction):
→ Prompt better: add constraints, examples, output schemas → Try a different model: some models are better at code, others at following instructions → Decompose harder tasks into smaller pieces → Fine-tune (last resort only — costly, save for the final few %)
The order matters.
Fix prompts first. Try a different model. Decompose further. Fine-tune last.
Most teams reach good enough quality at step 2.
## 13. Latency and Cost
Quality first. Then speed and cost.
Reducing latency:
1. Measure every step. Find the real bottleneck.
2. Parallelize anything that doesn't depend on another step.
3. Right-size models — fast cheap LLM for simple steps, big model for reasoning.
4. Try faster providers — token streaming speeds vary a lot.
5. Trim context — shorter prompts decode faster.
Reducing cost:
Real cost breakdown for a typical research agent run:
→ LLM generation calls: ~$0.04 → Web search API calls: ~$0.02 → Embedding calls: ~$0.005 → Infrastructure: ~$0.015 → Total per run: ~$0.08
At 1,000 runs/day = $80/day = $2,400/month.
How to cut it:
→ Attack the biggest buckets first → Tier your models — cheap for easy, expensive for hard → Cache results aggressively (search results, embeddings, summaries) → Constrain outputs ("Return JSON. 5 fields max.") → Batch operations where possible
## 14. Observability: Watching Your Agents at Scale
Traditional software: trace the execution path. A calls B. B calls DB. Returns result.
AI agents don't work like that.
They're non-deterministic. Same input → different output. Distributed execution. External dependencies that can fail.
You need two kinds of visibility:
Zoom-in metrics (single run debugging)→ Full trace: every prompt, every tool call, every token used → Why did the agent choose this tool? → What did each step return? → Where exactly did it fail?
Log not just what happened but why: "Agent chose web search instead of RAG because query contained 'recent'" "Reflection identified 3 issues: missing citation, vague date, wrong tone"
Zoom-out metrics (system health across many runs)→ Quality scores over time → Hallucination rates → Success rates → Are changes helping or hurting?
You can't inspect every trace manually at scale.
Use quality sampling — evaluate a percentage of all runs. Build a trend line.
This is how you catch regressions before users do.
## 15. Security: The Part Nobody Talks About (But Should)
Security for AI agents is not like traditional app security.
You're not just protecting against external attackers.
You're protecting against your OWN system making dangerous decisions.
The threats:
→ Prompt injection — malicious content in user input hijacks the agent's instructions → Unsafe code generation — agent writes code that accesses sensitive data or does harmful things → Data leakage — PII or proprietary info exposed through outputs or tool calls → Resource exhaustion — agents spinning infinite loops or burning expensive API calls
Code execution is the riskiest feature.
If you enable it, here's how to do it safely:
→ Sandbox in Docker. Container gets destroyed after each run. → Set hard resource limits: timeouts, memory caps, CPU limits → Whitelist only specific safe libraries → Validate all inputs before they reach the agent → Scan all outputs for sensitive data (API keys, PII) → Use deterministic I/O — code returns structured JSON, not free-form text to users
Most teams learn these lessons the hard way.
Read this before you ship.
That's the complete course.
## RECAP
BEGINNER:→ Agents work iteratively — plan, act, observe, repeat → Best for complex multi-step tasks that can handle ~90% accuracy → Start semi-autonomous, not fully autonomous → Context engineering is the real intelligence → Task decomposition is the most important skill
INTERMEDIATE:→ Eval from day one — LLM-as-judge for complex tasks → Memory (dynamic) ≠ Knowledge (static) → Three types of guardrails: code → LLM judge → human → 4 patterns that always help: reflection, tool use, planning, multi-agent → Start sequential. Add coordination complexity only when needed.
PRODUCTION:→ 4 decomposition patterns: functional, spatial, temporal, data-driven → Fix prompts before fine-tuning → Measure latency and cost per step, then attack the biggest buckets → Two observability modes: zoom-in traces + zoom-out health metrics → Security = protecting against your own system, not just attackers
Most people start building agents.
Few people ship agents that work reliably at scale.
The gap is everything in this article.
If this was useful:
→ Repost to share it → Follow @sairahul1 for more breakdowns like this → Bookmark this — you'll reference it while building
I write about AI systems, building products, and automation that works while you sleep.
## 相关链接
- [Rahul reposted](https://x.com/sairahul1)
- [Rahul](https://x.com/sairahul1)
- [@sairahul1](https://x.com/sairahul1)
- [101K](https://x.com/sairahul1/status/2058464422306443766/analytics)
- [@sairahul1](https://x.com/@sairahul1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:25 PM · May 24, 2026](https://x.com/sairahul1/status/2058464422306443766)
- [101.4K Views](https://x.com/sairahul1/status/2058464422306443766/analytics)
- [View quotes](https://x.com/sairahul1/status/2058464422306443766/quotes)
---
*导出时间: 2026/5/25 09:58:59*
---
## 中文翻译
# AI Agents: 全方位指南
**作者**: Rahul
**日期**: 2026-05-24T08:25:37.000Z
**来源**: [https://x.com/sairahul1/status/2058464422306443766](https://x.com/sairahul1/status/2058464422306443766)
---
在 2026 年，每个人都在谈论 AI Agent。
但大多数人根本不知道它们实际上是如何工作的。
从今天开始，这将发生改变。
我花了数周时间提炼了一切：课程、书籍、实际的构建过程、生产环境的失败案例。
以下是你真正需要了解的内容。
无论你是想自动化自己的工作流，还是为公司构建生产级 AI 系统 —— 这都是你的路线图。
请收藏本文。内容很长。但物有所值。
## 第一部分：入门 AI Agent 实际上是什么
## 1. 什么是 AI Agent？
普通的 LLM 只做一件事：
你提问。它回答。结束。
一次性的。线性的。没有迭代。
AI Agent 的工作方式不同。
它的工作方式就像你在处理艰巨任务时的实际操作：
→ 先计划 → 调查研究 → 起草 → 审查自己的工作 → 修改 → 重复
这被称为 ReAct 循环：
推理 → 行动 → 观察 → 重复
模型推理下一步做什么。行动（通常通过调用工具）。观察结果。然后要么给你答案，要么循环回去。
为什么这很重要？
每一次循环都会增加深度。更强的推理能力。更少的幻觉。更好的组织性。
这些都是当你试图一次性解决问题时会失去的东西 —— 而 Agent 能把它们找回来。
## 2. Agent 到底适合用来做什么？
并非每个任务都需要 Agent。
正确的思维模型：一个 2x2 矩阵。
坐标轴：复杂度 vs 所需精度。
→ 低复杂度 + 高精度 = 直接写代码 → 低复杂度 + 低精度 = 直接使用单次 LLM 提示 → 高复杂度 + 高精度 = 带有严格防护栏的 Agent（税务表单、法律文件） → 高复杂度 + 低精度 = 最佳的切入点
最后一个象限是你能最快取得早期胜利的地方。
完美的 Agent 任务示例：
→ 调查研究并撰写报告
→ 回复客户邮件（查询订单 → 起草回复）
→ 处理发票
→ 保存到数据库
→ 通过实际检查库存来回答“你有 80 美元以下的蓝色牛仔裤吗？”
当任务需要以下条件时，Agent 表现出色：
→ 多个步骤
→ 外部信息
→ 迭代和自我修正
如果你用一个提示就能解决它 —— 不要构建 Agent。
## 3. 自主度谱系
构建 Agent 时的第一个重大决策：
你给它多少控制权？
想象一个谱系。
脚本化（左端）
你硬编码每一个步骤。
→ 生成搜索词
→ 调用网络搜索
→ 获取页面
→ 撰写文章。
模型只负责文本生成。其他所有事情由你决定。可预测。易于调试。功能有限。
半自主（中间）Agent 从你定义的工具中进行选择。在你设定的防护栏内做出决策。这是大多数实际生产系统所处的位置。
全自主（右端）LLM 决定一切。搜索什么。获取多少页面。是否反思。是否编写新代码并运行它。功能更强大。更难控制。
你应该从哪里开始？
谱系的中间。给它提供工具。设置防护栏。只有在建立了信心后才增加自主权。
## 4. 上下文工程
这才是真正让 Agent 变得“智能”的东西。
不仅仅是模型本身。
而是你在其周围构建的上下文。
上下文工程 = 决定 Agent 在每一时刻拥有什么信息。
这包括：
→ 背景 —— 任务是什么，用户是谁
→ 角色 —— “你是一位专门从事市场分析的研究 Agent”
→ 记忆 —— 之前的步骤中发生了什么
→ 可用工具 —— 它可以调用哪些函数
→ 知识 —— 它可以参考的文档、数据库、PDF
做好工程 → 模型行为一致。
工程糟糕 → 不可预测的垃圾。
无论哪种情况，模型都是一样的。
上下文是区分优秀 Agent 和糟糕 Agent 的关键。
## 5. 任务分解
构建 Agent 时最重要的技能。
首先问：人类会如何完成这项任务？
然后针对每一步问：LLM 能做到吗？需要一点代码？还是 API 调用？
如果答案是否定的 → 将其拆分得更小，直到可以做到。
示例 —— 撰写文章的 Agent：
1. 大纲 → LLM 生成结构
2. 搜索词 → LLM 生成，然后调用搜索 API
3. 获取页面 → 工具调用
4. 撰写草稿 → LLM 使用获取的资源
5. 自我批评 → LLM 列出差距和弱点
6. 修订 → LLM 根据批评重写
每一步都是： → 小规模 → 可检查 → 具有清晰的输入和输出
当最终输出不好时，你确切知道哪一步需要修复。
这就是分解的超能力。
## 第二部分：中级 构建真正有效的多 Agent 系统
## 6. 评估（区分专业人士和爱好者的枯燥工作）
没人愿意谈论评估。
每个发布真实系统的人都在做。
如何衡量你的 Agent 是否在工作？
简单任务 → 计算正确答案的数量。客服机器人正确回答了库存问题吗？是/否。
复杂任务 → 使用 LLM 作为评判者。让第二个模型使用固定的评分标准对输出进行 1-5 分打分。文章论点是否有力？引用是否恰当？语气是否正确？
你需要两个级别的评估：
→ 组件级 —— 每个单独的步骤都有效吗？（搜索查询是否足够具体？批评意见是否提供了真实的反馈？）
→ 端到端 —— 最终输出好吗？（文章真的写得好吗？）
如果端到端失败但组件评估通过 → 交接问题。如果特定组件失败 → 该 Agent 需要改进。
从第一天就开始评估。不要等到有一个“完美”的评估系统。快速发布一些东西并迭代。
## 7. 记忆与知识
两个非常不同但人们容易混淆的概念。
记忆 = 动态的。每次运行都会更新。
→ 短期：Agent 在工作时做笔记。其他 Agent 可以阅读这些笔记。 → 长期：任务完成后，Agent 进行反思。什么做得好？什么没做好？存储经验教训。
下次运行 → 加载这些教训 → 应用它们。
这就是你在不进行微调的情况下“训练”Agent 的方式。提供反馈 → Agent 在每次运行中改进。
知识 = 静态的。预先加载。
→ PDF、CSV、内部文档、数据库访问 → Agent 的参考资料库 → 给它一次。它在需要时随时从中提取信息以获得准确的答案。
可以这样想：
记忆 = 你从经验中学到的东西。知识 = 你可以参考的教科书。
两者都很重要。其中一个不能替代另一个。
## 8. 防护栏
一个能工作的 Agent 并不一定是安全的 Agent。
LLM 是非确定性的。
它们可能会弄错格式、陈述错误的事实、偏离任务。
防护栏是“Agent 说它完成了”和“任务真正完成”之间的质量门。
三种类型：
类型 1 — 代码检查（快速 + 便宜）用于确定性的事情。 → 输出格式正确吗？长度对吗？必填字段存在吗？编写一个简单的验证函数。立即运行。只要可能，始终优先使用此方法。
类型 2 — LLM 评判者用于细微的质量检查。 → “此回复是否与源文档在事实上一致？” → “语气是否专业且积极？” 如果评判者说否 → 解释原因 → Agent 修改 → 再试一次。
类型 3 — 人在回路用于高风险决策。Agent 在最终确定之前停止。发送输出供人工审查。人工批准、拒绝或请求更改。
大多数生产系统至少使用这三种中的两种。
9. 提升每个 Agent 的 4 种设计模式
这四种模式可靠地让 Agent 变得更好。
模式 1：反思
不要在初稿就停下来。
模型生成输出 → 批评它 → 根据批评重写。
邮件 v1：“嘿，我们下个月见面吧。谢谢。” 批评：日期模糊、没有署名、语气太随意。邮件 v2：“嗨 Alex，我们在 1 月 5-7 日见面吧。告诉我什么时间合适。祝好，Sai。”
在代码方面更强大 —— 编写它，运行它，捕获错误，反馈，模型修复。
用于：结构化输出、长文写作、代码、程序步骤。
模式 2：工具使用
给 LLM 一个它可以调用的功能菜单。
模型决定何时以及使用哪个工具。
网络搜索。数据库查询。代码执行。日历。邮件。API 调用。
LLM 无法单独完成这些。工具是 Agent 与世界互动的方式。
模式 3：规划
让 Agent 决定步骤，而不是固定的流水线。
给它一个工具包。提示它制定计划。一步步执行。
零售示例：“有 100 美元以下的圆框太阳镜吗？” Agent 计划：搜索描述 → 检查库存 → 按价格过滤 → 回答。
你没有编写这些确切的步骤。Agent 选择了它们。
模式 4：多 Agent 协作
将复杂的工作分配给专门的 Agent。
研究员 → 设计师 → 作者。
每个 Agent 都擅长其特定的工作。输出更好，因为没有单个 Agent 试图做所有事情。
## 10. 多 Agent 系统设计
你实际上如何构建多 Agent 系统？
四种协调模式，从最简单到最复杂。
模式 1：顺序型每个 Agent 完成 → 将输出传递给下一个 Agent。像一条流水线。研究员 → 设计师 → 作者 → 完成。易于调试。可预测。从这里开始。
模式 2：并行型同时运行独立的 Agent。研究员 + 设计师同时工作。作者结合他们的输出。更快。协调复杂性更高。
模式 3：管理者层级一个管理者 Agent 协调专家。管理者计划、委派、审查。专家向管理者汇报，而不是互相汇报。这是当今真实生产系统中最常见的模式。
模式 4：全互联任何 Agent 都可以给任何其他 Agent 发消息。混乱。难以预测。仅适用于允许变化的创意/低风险工作。不要在生产中使用。
经验法则：从顺序型开始。仅在需要时增加复杂性。
## 第三部分：生产环境 实际上如何从原型到交付
## 11. 高级任务分解
在复杂的多 Agent 系统中，你如何分解任务非常重要。
4 种模式：
功能型 — 按技术领域拆分。前端 Agent。后端 Agent。数据库 Agent。工程团队的经典做法。
空间型 — 按文件或目录结构拆分。Agent 1 处理 /services/users/。Agent 2 处理 /services/orders/。适用于大型代码库。最大限度地减少冲突。
时间型 — 按连续阶段拆分。阶段 1：研究。阶段 2：计划。阶段 3：构建。阶段 4：发布。每个阶段在下一个开始前完成。
数据驱动型 — 按数据分区拆分。Agent 1 处理第 1 周的日志。Agent 2 处理第 2 周。以此类推。适用于大型数据集。并行化分析。
你可以混合使用这些。
主要结构的功能分解 + 每个 Agent 内部的时间分解。
使用适合你任务自然边界的任何方式。
## 12. 提高生产环境中的质量
系统在工作但不够好。
两种类型的组件。两种不同的修复策略。
非 LLM 组件（网络搜索、RAG、OCR、代码执行）：
→ 调整旋钮：搜索日期范围、top-k 结果、块大小、相似度阈值 → 更换提供商：尝试不同的搜索 API、视觉模型、解析器
LLM 组件（生成、推理、提取）：
→ 更好的提示：添加约束、示例、输出模式 → 尝试不同的模型：有些模型更擅长代码，有些更擅长遵循指令 → 将更难的任务分解为更小的部分 → 微调（仅作为最后手段 —— 成本高昂，留给最后的几个百分点）
顺序很重要。
首先修复提示。尝试不同的模型。进一步分解。最后微调。
大多数团队在第 2 步就能达到足够好的质量。
## 13. 延迟和成本
质量第一。然后是速度和成本。
降低延迟：
1. 衡量每一步。找到真正的瓶颈。
2. 并行化任何不依赖其他步骤的操作。
3. 调整模型大小 —— 快速便宜的 LLM 用于简单步骤，大型模型用于推理。
4. 尝试更快的提供商 —— token 流式传输速度差异很大。
5. 精简上下文 —— 更短的提示解码更快。
降低成本：
典型研究 Agent 运行的实际成本明细：
→ LLM 生成调用：约 $0.04 → 网络搜索 API 调用：约 $0.02 → 嵌入调用：约 $0.005 → 基础设施：约 $0.015 → 每次运行总计：约 $0.08
每天 1,000 次运行 = 每天 $80 = 每月 $2,400。
如何削减：
→ 首先解决最大的开销 → 对模型进行分层 —— 简单任务用便宜的，困难任务用昂贵的 → 积极缓存结果（搜索结果、嵌入、摘要） → 限制输出（“返回 JSON。最多 5 个字段。”） → 尽可能批量操作
## 14. 可观测性：大规模监控你的 Agent
传统软件：跟踪执行路径。A 调用 B。B 调用数据库。返回结果。
AI Agent 不是那样工作的。
它们是非确定性的。相同的输入 → 不同的输出。分布式执行。可能失败的外部依赖。
你需要两种可见性：
放大指标（单次运行调试）→ 完整跟踪：每个提示、每个工具调用、使用的每个 token → Agent 为什么选择这个工具？ → 每一步返回了什么？ → 它到底在哪里失败？
不仅记录发生了什么，还要记录原因：“Agent 选择网络搜索而不是 RAG，因为查询包含‘最近’” “反思发现了 3 个问题：缺少引用、日期模糊、语气错误”
缩小指标（多次运行中的系统健康状况）→ 一段时间内的质量分数 → 幻觉率 → 成功率 → 变化是有帮助还是有害？
在大规模情况下，你无法手动检查每条跟踪。
使用质量抽样 —— 评估所有运行的百分比。建立趋势线。
这就是你在用户之前发现回归问题的方法。
## 15. 安全：没人谈论（但应该谈论）的部分
AI Agent 的安全不像传统的应用安全。
你不仅仅是防御外部攻击者。
你还要防御你自己的系统做出危险的决定。
威胁：
→ 提示注入 —— 用户输入中的恶意内容劫持 Agent 的指令 → 不安全的代码生成 —— Agent 编写访问敏感数据或造成伤害的代码 → 数据泄露 —— PII 或专有信息通过输出或工具调用暴露 → 资源耗尽 —— Agent 陷入无限循环或消耗昂贵的 API 调用
代码执行是风险最高的功能。
如果你启用它，安全操作方法如下：
→ 在 Docker 中沙盒化。容器在每次运行后被销毁。 → 设置硬性资源限制：超时、内存上限、CPU 限制 → 仅将特定安全库列入白名单 → 在输入到达 Agent 之前验证所有输入 → 扫描所有输出中的敏感数据（API 密钥、PII） → 使用确定性 I/O —— 代码返回结构化的 JSON，而不是给用户的自由文本
大多数团队都是通过惨痛的教训才学到这些的。
在发布之前阅读本文。
这就是完整的课程。
## 总结
入门：→ Agent 迭代工作 —— 计划、行动、观察、重复 → 最适合可以接受约 90% 准确率的复杂多步骤任务 → 从半自主开始，而不是全自主 → 上下文工程才是真正的智能 → 任务分解是最重要的技能
中级：→ 从第一天开始评估 —— 复杂任务使用 LLM 作为评判者 → 记忆（动态）≠