动手做个Agent - Presentation Agent实践
两个月前趁着claude code比较火，上手直接试了一下用它来做一个presentation agent的saas服务。整体感觉是claude code这类代码工具可以极大的提高开发的效率，尤其是在不熟悉的前端开发的时候，完全是靠模型帮忙端到端生成的。虽然claude code在体验上还是有挺多问题，但是还是非常值得推荐开发同学去体验尝试，关于claude code的使用体验，后面有时间再慢慢聊吧，今天简单聊聊这个presentation agent的内容。
整体效果
只能说效果一般，要做好还有很多地方要打磨。
Landing Page
工作页面
结果预览
PC端
移动端：
设计思路
首先我们生成的不是PPT，而是演示页面，那么基于现有的大模型在生成静态页面能力这么强的基础上，我们选择直接生成HTML页面。
我们采用的是workflow的形式来生成完整的内容，主要划分成以下三个步骤：
1.根据用户需求生成内容大纲
2.根据大纲生成每页的主要内容
3.生成演示页面
其实做下来发现，核心的难点还是信息的收集，本质上我们做的是类似Deep Research做的事情，只是顺便把结果结构化成不同的页面。
Agent
为了完成前面提到的3个任务，我们设计了3个不同的Agent，分别生成大纲，内容和网页。这里给Agent配备的工具只有搜索（serper.dev)和fetch(MCP工具），利用json_object作为输出结构，方便解析，同时限制了agent的最大调用次数，避免陷入死循环。
Outline Agent
Outline很简单，纯粹的prompt驱动
| Plain Text 你的任务是根据用户的描述生成大纲。 大纲包含{num_topics}个子主题，每个子主题包含 3-5 个要点。 要求： - 如果你对用户的描述内容不清楚，或者是涉及时效性的信息，使用搜索工具获取最新的信息来帮助你理解 - 在搜索到相关链接后，可以使用 {fetch_tool} 工具来阅读页面的详细内容。 - **最终必须返回有效的JSON格式**，严格遵循以下 Pydantic 模型的定义： {Outline.model_json_schema()} **重要**：无论如何都必须输出符合上述schema的JSON对象，即使信息不完整也要返回一个基本的大纲结构。 |
最终输出：
Search Agent
前面Outline Agent已经生成结构化的数据，那么Search Agent就可以并行执行，分别去收集每一块内容。
最终输出
Html Agent
有了前面的内容，Html Agent内部其实也是个workflow，分成主题样式设计、封面页生成、目录页生成、内容页生成几个步骤。
问题和反思
开发效率问题
整体前前后后利用下班时间，从开始到最终部署到自己的网站，利用claude code花了大概1-2个月（包括中间有几个星期忙工作，没时间搞，只能说是断断续续）。
开发模式基本是我会跟claude聊想法，然后转化成github项目上的issue或者feature，然后每天就跟claude code说要解决哪个feature，看它写代码然后review，但是中间claude code会限制使用次数，往往就会造成干到一半就停工，等第二天再接着搞的情况，浪费了挺多时间，如果买个更高级的claude会员应该会好很多。
另外也没有用现有的Agent SDK，比如langgraph，所有的开发（比如上下文管理，MCP集成）都是从头撸的，也花费了一些时间，不过好处是对细节把控更到位一些。
在服务开发期间，比较大的问题我感觉还是claude对于代码库复杂的情况下，很多细节没有理解，会导致没有复用原来的接口能力，重复造轮子，即浪费时间也浪费使用次数。当然也跟我的claude.md没去更新管理有关，每次都是让它重新理解代码，只能说我自己对代码库的上下文管理还不到位。
使用claude-monitor可以方便了解用量，对当前工作有预期。
信息收集模块
Search Agent这里问题挺多，包括：
1.Search Agent为了提高效率，是采用并行的方法去执行的，每个Agent只负责大纲的一部分，就会造成Agent对整体的内容缺乏一个把控，会重复去同一个来源获取信息，这势必导致token的浪费和生成的部分内容和其他Agent有重复。同时生成的内容会过于丰富，导致后面生成页面的时候信息过多，增加页面复杂度。 一个稍微好点的方法可能是只靠一个Agent去完成所有的信息收集，但是这对agent的能力要求就比较高了。另外就是将Agent返回的结果再做一次汇总。
2.Token用量极高，这里我主要限制了搜索和fetch的使用次数，以及fetch内容的长度。看下面图，内容生成就花费了900K的token，而且大部分都是输入token。一个更好的策略应该是用更小更便宜的模型，对网页的内容根据query做个理解总结再返回，而不是直接将网页原始内容作为输入。
3.图片问题。在Search Agent中，我们获取图片的方法主要是两种，一个是根据网页的内容，模型自己判断哪些图片链接是有用的，另外就是直接进行图片搜索，这就导致我们无法判断图片的质量，以及图片是否跟内容相关。比如会出现质量差的图片，或者有水印的图片，有大量文字的图片，给最终的页面相关呈现不好的情况；另外我们不下载图片（其实如果下载图片的话好一些，由于某些扣扣搜搜的原因我选择不下载），会出现链接失效或者无法显示的问题，同时图片的尺寸未知，无法提前跟紧图片尺寸设计它在页面上的位置和呈现形式。
比如下面Iphone的图片显示不完整，被截断：
海报图片缺失：
正如前面提到了，解决方法包含：1、将图片下载到本地，这样保证图片有效以及获取图片大小。2、使用一个多模态模型对图片做一层理解，分析它的内容
HTML生成
HTML生成的难点是评估效果，每次都只能根据自己的感觉来调整prompt或者流程，开发效率挺低了，还是那句话，Agent的前提是能有效定义好评估的标准，最好能够自动化的评估，不然没法快速迭代。
相对来说，封面页和目录页是好设计的，只要prompt调整的好，基本都能生成还不错的效果，但是内容页就比较难了，对于我这种没有设计美学的人来说，只能看它整体布局是不是简洁清晰，有没有明显的问题。
我这里只列举一些我觉得还不够好的地方
1.页面布局不对齐，比如下面这种：
2.内容分布不合理，有的多，有的少
3.图片失效和尺寸问题，这个前面已经提过了
4.不同的页面，有的内容有的长一些，有的短一些，这个主要是没有限制页面尺寸，限制尺寸会带来的问题就是内容溢出，二者要做权衡
5.配色有点土有时候，不够现代，比如下面的，蓝色没问题，但是整体我就感觉不是很好看
