企业官网建设流程全解析

声明：本篇博客是以吴恩达的【Agent智能体】教程为基础，并对其中的内容做了笔记整理以及个人收获的总结。

问题引入：你应该把精力集中在哪些方面来优化工作流程？

答案：衡量团队效率和水平的最大指标之一，就是他们是否能够有条不紊地进行错误分析从而指导你将精力集中在最关键的地方。所以这篇文章主要讲解的是如何进行错误分析。先看一个例子

例子：Research Agent（研究智能体）

这个评估结果表展示了智能体在处理不同 Prompt（提示词）时的表现和存在的 Issues（问题）：

• 黑洞科学研究：漏掉了近期新闻大量报道的高调研究成果。
• 西雅图租房vs买房：表现得还不错。
• 水果采摘机器人：没有提到该领域的领先设备公司。

结论：智能体“有时会遗漏人类本应指出的关键信息”。这构成了错误分析的表象——我们知道结果不完美，但还不知道问题出在哪一步。

针对上一张图中发现的“遗漏信息”问题，这张图提出了具体的假设性归因（Possible causes）。将整体的失败拆解到了工作流的每一个节点上：

• Bad search terms?（搜索词太差？）：是不是第一个 LLM 提取的搜索关键词不够精准，导致一开始方向就错了？
• Low quality search results?（搜索结果质量低？）：是不是搜索 API 本身返回的结果就不包含那些重要信息？
• Poor selection of sources?（信息源筛选不佳？）：是不是搜索结果里其实有重要信息，但在“挑选最好的 5 个来源”时，LLM 把关键文章漏掉了？
• Bad reasoning over texts?（文本推理能力差？）：是不是关键文章都被正确抓取了，但在最后一步“写草稿”时，LLM 没能理解或总结出重点？

“Examine traces to better understand each step in the workflow”（检查运行轨迹以更好地理解工作流中的每一步）

有些团队会凭借直觉选择其中一个环节来优化跟改进，其实更好的方法是进行错误分析，深入理解工作流程中的每一步，可以经常检查模型的推理过程记录，也就是每一步之后的中间输出结果（跟debug差不多🤔 ），这样可以判断哪个环节的表现不佳。下面看一个例子

检查运行轨迹（Looking at traces）

术语理解：

• 所有中间步骤的整体输出集合，通常被称为该智能体运行的“追踪（Trace）”
• 单步输出有时候被称为“跨度（Span）”

检查每一个步骤：

• 第一步：LLM 生成搜索词 (灰色框)
  • 日志显示：模型生成了 “Black hole theories Einstein”、“New physics black holes” 等词。
  • 诊断：没有明显的逻辑错误。
• 第二步：执行网页搜索 (绿色框) —— 问题！
  • 日志显示：搜索引擎返回的结果是：“小学生破解了30年的黑洞谜题（来自 astrokidnews.com 星际儿童新闻）”，还有“Bob Lee在院子里看到天空有亮光…”。
  • 诊断：这里的搜索结果质量极差（Low quality search results）。系统抓取到了大量不靠谱的八卦新闻、儿童读物或个人博客，根本没有触及真正的科学前沿报道。
• 第三步：筛选最佳信息源 (灰色框) —— 问题！
  • 日志显示：负责“挑选5个最佳来源”的 LLM，竟然把这些极其离谱的网址（比如spacefunnews.com太空趣味新闻、astronautme.com）作为权威资料挑了出来。
  • 诊断：信息源筛选逻辑（Poor selection of sources）也存在大问题。大模型没有能力辨别哪些是学术期刊，哪些是地摊文学。

这样我们就可以得出结论：

如果你只看最终输出的文章，你可能会觉得“这个写文章的大模型太笨了，连近期大热的黑洞新闻都不知道”。

但看了 Trace 之后，你立刻就能知道：根本不是最后一步写文章的模型不行，而是它吃进去的“食材”全是垃圾（Garbage in, garbage out）。

后续优化的优先级立刻就清晰了：

1. 限制搜索源：不要用通用的 Google 搜索，而是让web search工具专门去检索 arXiv、Nature、Science 等学术网站或主流新闻媒体。
2. 优化筛选 Prompt：在“挑选5个最佳来源”那一步，强烈要求 LLM 过滤掉非学术后缀或名字看起来像娱乐新闻的网站。

这张图生动地说明了：直觉往往会骗人，只有深入查看 Trace，才能找到真正的 Bug 所在。

建一个表格，统计错误发生的位置

这叫做基于数据的错误量化分析 (Quantitative Error Analysis)。我们来拆解这张图：

1.建立错误矩阵 (Error Matrix)

图中的表格不再是单次运行的记录，而是一个综合的测试评估表：

• 每一行 (Rows)：代表测试集里的一个具体 Prompt（测试用例）。
• 每一列 (Columns)：依然代表工作流中的各个独立步骤（搜索词生成、获取搜索结果、挑选最佳信息源等）。
• 单元格内容：记录了在批量跑测试时，每个用例具体是在哪一步出现问题的，以及具体原因。
  • 比如“黑洞科学”这一行，错误出在【搜索结果】列，原因是“博客太多，学术论文太少”。
  • 比如“水果采摘机器人”，在【搜索词】列就出错了（词太宽泛），导致【搜索结果】列也错了（搜出了小学生网站）。

2.图表底部的数字

这张图最有价值的信息是表格底部红色的百分比：5%, 45%, 10%…

这是将成百上千个测试用例跑完后，统计出的各步骤总体错误率：

• 【生成搜索词】环节只占了总错误的5%。
• 【获取搜索结果】环节居然占了总错误的45%！
• 【挑选 5 个最佳来源】占了10%。

3.这张图带来的巨大工程价值：指明优化方向

在软件工程和 AI 开发中，资源（算力、人力、时间）永远是有限的。这张图完美解决了团队开会时最常争吵的问题：“我们接下来该优化哪里？”

看完这个统计图，结论呼之欲出：绝对不要把时间浪费在去抠“生成搜索词”的 Prompt 上了（它只占 5% 的问题），甚至也不用急着去优化“挑选来源”的模型。目前整个系统的最大瓶颈（Bottleneck）在【获取搜索结果】这一步（45%）！

团队接下来的 Action Item（行动计划）立刻就明确了：

• 是不是用的搜索引擎 API 不对？（比如把通用的 Bing Search 换成 Google Scholar 或专门的学术 API）。
• 是否需要在搜索工具里强制加上限定词过滤器？（比如过滤掉.com域名，只留.edu或.org）。
• 是否需要引入混合检索（Hybrid Search）或者 RAG 技术来提升召回质量？

总结

这三张图连在一起，构成了一个极具专业水准的大模型 Agent 开发方法论：

1. 直观感知：发现最终结果不好。
2. 微观定性（Trace）：拆解工作流，深入查看单次调用的中间结果，弄清错误是如何发生的。
3. 宏观定量（Counting Errors）：批量运行测试，统计各环节的错误比例，找出最大瓶颈，集中火力进行优化。

错误分析的建议

1. Develop a habit of looking at traces（养成查看运行轨迹的习惯）

   • 不要只看最终结果，要习惯性地去翻看系统运行的中间日志（Traces）。

   • 解析：这是解决“黑盒化”的第一步。就像我们前面看的第二张图一样，只有打开 Trace，你才能看到模型到底生成了什么搜索词、外部工具返回了什么原始数据。这要求开发者在搭建 Agent 时，必须接入日志监控工具（如 LangSmith 等），让每一次调用都“有迹可循”。

2. Carry out error analysis to figure out what component performed poorly, leading to a poor final output（进行错误分析，找出导致最终输出不佳的具体组件）

   • 当结果很差时，要顺藤摸瓜，找出到底是哪一个特定的步骤（组件）掉了链子。

   • 解析：这一步强调的是“定位根因”。因为在复杂的工作流中，错误是会放大的（级联错误）。最终文章写得烂，可能不是因为负责写文章的 LLM 差，而是因为第一步的检索工具给了一堆垃圾信息。必须精准定位到具体的“案发地点”。

3. Use error analysis output to decide where to focus efforts（利用错误分析的结果，决定将精力集中在哪里）

   • 根据你统计出来的错误数据，来决定接下来的开发工作该把时间花在哪个环节上。

   • 解析：这完美对应了我们刚才那张“统计错误率 (45%, 10%, 5%)”的表格！开发资源（时间和算力）是宝贵的，你要把精力投入到 ROI（投资回报率）最高的地方。如果数据告诉你 45% 的错误都来自“搜索结果质量低”，那你就应该把整个团队的精力都放在优化搜索引擎上，而不是去瞎调其他环节的代码。

总结：这三条建议构建了一个闭环：看日志 -> 定位错误组件 -> 集中火力解决最大痛点。

如果这篇文章对你有帮助，欢迎点赞、评论、关注、收藏。你们的支持是我前进的动力！