本文探讨了 AI Agent 的核心价值在于工作流设计而非概念本身。文章指出，思维链（CoT）是提升生成质量的关键，而非单纯的 Agent 数量。设计适合 AI 的工作流需遵循四大原则：避免过度拟人化、采用人机协作决策模式、结合多领域工具模型、回归问题本质。通过 PDF 转 Markdown 和漫画翻译的案例，展示了如何利用 PyMuPDF、OCR 及视觉模型构建高效自动化流程。此外，文章还补充了工程化落地时的延迟控制、成本优化及可观测性等关键考量，强调了基于问题本质设计解决方案的重要性。
现在 AI 智能体（AI Agent）的概念非常火热，似乎 Agent 是用 AI 解决问题的银弹，有了 Agent 就可以解决很多问题。但也有很多人持有不同意见，认为 Agent 不过是噱头，并没有看到靠谱的应用场景。
一个被提及很多的是吴恩达老师写的多 Agent 翻译的例子，简单来说就是用三个 Agent：一个直译 Agent、一个审查 Agent、一个意译润色 Agent，确实可以大幅提升翻译质量。
但并非一定要三个 Agent 才能提升翻译质量，基于 Prompt 的翻译方法，让 LLM 在翻译时，使用直译 + 反思 + 意译三个步骤输出，也可以得到高质量的翻译结果。
本质上，使用 LLM 来解决问题，思维链（CoT，Chain of Thought）是一种有效提升生成质量的方法。也就是说，之所以翻译质量能提升，不是因为有了 Agent，而是因为有了思维链。至于思维链的每个环节是用一个独立的 Agent，还是输出的一个步骤，并没有太本质的差别。
其实大部分 AI 应用场景都类似：要用 AI 解决问题，核心不在于 Agent，而在于设计出一个适合 AI 的工作流。
那么怎么才能设计一个适合 AI 的工作流呢？我认为有几个关键因素需要考虑：
有时候我们过于将 AI 拟人化，会不自觉的用人类解决问题的方式来套用在 AI 上，有时候确实有效，但很多时候并不一定是最优解。就像专业的翻译员，他们并不需要直译反思意译三个步骤，他们可以一步到位，直接输出高质量的翻译结果，所以最开始让 AI 翻译，Prompt 都是直接一步输出翻译结果，而不是分步骤输出，结果翻译出来的比较生硬。
而当我们发现思维链是 LLM 的一种有效提升方法后，就可以设计出更适合 AI 的工作流，分成几步来解决问题。
包括我看到一些 Agent 项目，尝试模拟人类软件开发的分工，使用项目经理、产品经理、架构师、程序员、测试等等 Agent 角色去尝试解决复杂的软件项目，同样也是一个过于拟人化而不一定适合 AI 解决问题的思路，所以也只能出现在论文中，而无法在实际项目中落地。相反像 GitHub Copilot 这样辅助生成代码的工具倒是真正适合当前 AI 编程的工作流，能实实在在提升开发效率。
从技术实现角度看，人类开发流程包含大量的沟通成本和上下文切换，而 AI 在处理连续任务时，保持单一上下文窗口内的连贯性往往比频繁切换角色更有效。因此，在设计工作流时，应优先考虑减少状态管理的复杂度，利用 LLM 的长文本处理能力，而非强行拆分角色。
去年有一个超级火爆的项目叫 AutoGPT，就是你输入一个任务，GPT-4 会将任务分解，制定计划，调用外部工具，比如 Google 搜索，甚至执行代码，最终完成任务。这也算是 AI Agent 的先驱项目之一，但现在已经很少有人提及了，因为以现在 AI 的智能程度，还不足以对开放性的任务做出靠谱的决策，最终除了帮 OpenAI 卖了大量的 Token 外，并没有解决什么实际问题。
所以现在 AI 应用的主流是把 AI 当'副驾驶（Copilot）'，只是让 AI 辅助人类完成任务，主要还是人在做决策。
另外就是自己设计工作流，让 AI 在工作流中完成一部分工作，并不过于依赖 AI 做决策，或者只需要做简单的决策。比如说商家借助 AI 处理差评的工作流：
这是一个典型的设计好流程的适合 AI 的工作流，AI 只需要做简单的情感分析和回复生成，而不需要做复杂的决策，这样的工作流可以很好的提升效率，并且结果也相对靠谱。
在工程实践中，引入确定性规则作为边界条件至关重要。例如，在情感分析后，可以设定阈值，只有低于特定分数才触发人工介入，或者对于敏感词汇进行强制拦截。这种混合系统（Hybrid System）结合了 AI 的灵活性和传统规则的稳定性，是生产环境部署的首选模式。
去年起 AI 大热，一个很重要的原因是 LLM 的出现，这些模型一方面确实能力强大，有一定的通用性，有简单的推理能力，另一方面使用也简单，无论是通过聊天机器人，还是通过 API 调用，都能很方便的使用。
即使像我这样不是 AI 专业的人，也能很容易的使用这些模型。而在以前，AI 相对来说是个高门槛的领域，需要筛选数据、需要训练，还需要调参，对于非专业人士来说是很难使用的。
但这也导致一个问题，就是很多解决方案过于依赖 LLM，而不知道或者不会使用其他领域的 AI 模型，但当你能够根据任务，将不同领域的 AI 模型或者工具结合起来，设计出合适的工作流，就能够得到更好的解决方案。
例如，在处理图像识别任务时，专用的小模型可能比通用的 LLM 更准确且成本更低。在涉及数据库查询时，Text-to-SQL 模型配合预定义的 Schema 比让 LLM 自由发挥更安全。这种模块化设计允许我们在每个环节选择最优工具，从而构建出鲁棒性更强的系统。
上面提的几点都是容易犯的一些错误，之所以容易犯这些错误，恰恰是因为我们有时候过于关注一些流行的概念或技术，而忽略了要解决的根本问题是什么，将 AI 变成了目的而不是手段。如果你有了解马斯克的第一性原理思维，其强调的就是回归事物最基本的条件，把其解构成各种要素进行分析，从而找到实现目标最优路径的方法。
而运用第一性原理通常有三个步骤：
而这个思路也适用于我们去借助 AI 解决问题，设计出适合 AI 的工作流。
举两个设计合适 AI 工作流解决问题的例子，一个例子是 PDF 转 Markdown。
做过 PDF 翻译的都知道，要得到好的翻译结果，将 PDF 的内容整理成 Markdown，再让大语言翻译，效果是相当好的。但这个不好做，因为 PDF 是用来打印的格式，并不是结构化的数据，很难直接提取成 Markdown，再加上各种图表、表格等，更是复杂。
最近看到一个项目叫 PDFGPT，它就做的很巧妙，本质上是基于 GPT-4o 和 PyMuPDF 设计了一个工作流：
如果你纯粹依赖 LLM，恐怕无法完成这样的任务，一方面受限于上下文窗口的长度限制，一次无法处理多页 PDF，另一方面对于图片、图表、表格等内容无法嵌入 Markdown 中。如果结合 PyMuPDF 这样的库和一个简单的工作流，就可以方便的实现 PDF 转 Markdown，生成的结果也挺不错。
另一个例子是漫画的翻译，有很多那种气泡文字的漫画，如果要翻译成其他语言，就需要将气泡文字提取出来，翻译后再放回去。漫画翻译的难点在于：
如果人工做会怎么做？可能是读懂漫画，翻译，然后用 Photoshop 这样的工具抹掉原来的文字，再放上翻译后的文字。可以想象这样的工作量还是不小的。
有一个开源项目 comic-translate，就做的很好，它也是设计了一个适合漫画翻译的工作流：
如果不考虑翻译质量的话，这几乎是一个全自动的工作流，效率相当高，成本也很低，最贵的部分是 GPT-4o 的 API，一页也才 $0.02 左右。就算加上人工审核对翻译结果和图片生成结果的处理，也是能比以前的人工翻译效率高很多。
在实际工程中，除了逻辑设计，还需要考虑性能、成本和可靠性。
多步工作流意味着多次 API 调用，累积延迟可能很高。在生产环境中，必须引入异步队列机制，如 Redis 或 RabbitMQ，来处理任务排队。同时，对于非实时任务，应采用后台处理模式，避免阻塞主线程。
Token 消耗是主要成本来源。可以通过缓存策略减少重复请求，例如对相同的 Prompt 和输入进行哈希缓存。此外，可以使用较小的模型处理简单任务，仅在大模型处理复杂推理时使用，从而优化成本结构。
由于 AI 生成的不确定性，建立完善的日志系统至关重要。记录每一步的输入、输出、耗时以及中间状态，有助于在出现问题时快速定位是 Prompt 问题、模型幻觉还是工具调用失败。引入评估指标，如准确率、召回率，可以帮助持续优化工作流。
从上面的例子可以看出，真正要用好 AI，让 AI 发挥最大效能，核心是还是要基于你要解决的问题，重新设计一个适合 AI 的工作流，让 AI 在工作流中完成它最擅长的工作，至于是不是 Agent，是不是 LLM，是不是 AI 帮你决策，都不是最重要的。
未来的趋势将是更加模块化和标准化的 AI 组件集成，开发者将更像是在组装乐高积木一样构建智能应用。掌握工作流设计的思维，比单纯追逐最新的 Agent 框架更为重要。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
