Agent-Fox (beta)

2025.12.05 工作记录

AI记忆系统：实现了旋转AI记忆池系统，为首页添加怀旧文章展示功能。通过精心挑选的历史文章片段，让访客能够感受到博客的成长历程和技术演进。记忆池会定期轮换，保持内容的新鲜感和多样性。

首页重设计：完成首页的AI增强改造，整合了记忆系统、智能推荐和动态内容展示。新的布局更加突出AI助手的交互性，同时保持了简洁优雅的设计风格。

浮动工具栏优化：添加了滚动方向检测功能，工具栏会根据用户的滚动行为智能隐藏和显示。向下滚动时自动隐藏以提供更大的阅读空间，向上滚动时立即显示方便快速访问。还添加了侧边栏切换、返回顶部和直达评论区功能。

Agent-Fox客户端升级：新增分屏模式和命令面板两种UI模式。分屏模式适合桌面端多任务操作，命令面板则为快捷键爱好者提供了高效的交互方式。版本更新至1.2.8，优化了重试逻辑和消息回滚功能。

Bug修复：完成了两个重要修复，解决了运行中发现的界面响应和交互问题。

2025.12.04 工作记录

搜索功能增强：大幅改进关键词搜索功能，新增布尔逻辑支持（AND、OR、NOT），让用户可以进行更精确的复合查询。优化了搜索结果的排序算法，提高了相关性匹配的准确度。

分屏聊天界面：重构了文章AI聊天面板，采用现代化的分屏设计。左侧显示对话历史，右侧是当前对话区域，充分利用宽屏显示器的空间优势。桌面端的体验得到显著提升。

工具描述优化：重构了所有MCP工具的描述文本，使用更简洁清晰的语言说明工具功能。统一了描述风格，让LLM更容易理解和选择合适的工具。

浮动工具栏修复：从根源上解决了浮动工具栏折叠按钮的bug，修复了点击区域不准确和响应延迟的问题。现在工具栏的展开和收起动作流畅自然。

AI代理增强：添加了页面类型感知的提示词选择机制。根据用户访问的是首页、文章页、搜索页等不同场景，动态调整AI的回复风格和功能重点。

提示系统改进：在关键词搜索结果中添加了智能提示，当snippet未直接包含答案时，会建议用户使用get_post_chunk获取全文。增加了💡图标和清晰的引导文字。

性能优化：重构了AJAX处理器，改进了验证逻辑和CORS处理。删除了废弃的MCP插件代码，减少了系统负担。

2025.12.03 工作记录

用户体验增强：为AI回复添加了思考时间显示、重试按钮和复制按钮。用户可以看到AI的”思考过程”，增加了交互的透明度。新增的开篇推荐问题按钮帮助新手快速开始对话。

Token统计显示：在前端增加了实时的token使用量统计，让用户了解每次请求的资源消耗。这对于控制API成本和提高使用效率很有帮助。

滚动冲突解决：通过检测滚动方向，解决了底部50px范围内用户滚动与自动滚动的冲突问题。添加了程序滚动标志，避免smooth动画干扰状态判断。

事件处理优化：改进了菜单交互，添加mousedown事件阻止blur，确保点击菜单项时不会触发输入框失焦。采用事件委托机制，避免了因DOM重建导致的事件丢失问题。

架构改进：将历史消息管理完全转移到后端处理，为后续实现动态上下文管理做准备。同时保留了tool use执行结果到上下文，确保对话的连续性。

跑马灯优化：对首页的动态内容展示进行了性能和视觉效果优化，减少了资源占用。

2025.12.02 工作记录

搜索策略简化：重新设计了搜索策略漏斗，简化了工具使用指南。让LLM能够更快速地选择合适的搜索工具，提高了响应效率。

Agent-Fox客户端更新：连续发布两个版本更新。1.0.8版本改进了工具调用布局和渲染效果，1.0.9版本专门增强了中日韩（CJK）标点符号的渲染支持，解决了亚洲语言显示问题。

提示词优化：改进了口号（catchphrase）的定义，增加了详细解释和示例，让AI的回复更加生动有趣。动态添加站点URL到提示词中，提高了引用规则的准确性。

参数验证增强：为相关搜索和随机搜索工具添加了日期参数验证和过滤功能，确保搜索结果的时效性和准确性。

2025.11.30 工作记录

首页改造完成：完成了首页布局的重新设计，增强了AI助手的交互体验。新的首页块模式（block pattern）让内容组织更加灵活，便于后续的功能扩展。

SaaS商业化报告：完成了SaaS商业化计划的交付报告，记录了从规划到实施的完整过程，为项目的商业化运营奠定了基础。

2025.11.26 工作记录

架构重构：引入统一核心基础设施层 (v2.0)，重构 Vector Connector 模块为分层架构；将 Python 服务迁移至 `/opt/ai-service/` 独立目录。

文档完善：为 react-agent-service 和 WordPress AI Agent 插件添加完整的开发文档和模块注释。

前端优化：完成前端资源整合和事件驱动管理；为代码块添加 Copy 复制按钮（sticky 定位，滚动跟随）。

UI 美化：美化后台管理页面；增强文章元数据显示，分类和标签支持点击跳转；优化目录组件最大高度。

Bug 修复：修复历史记录的权限问题；将 MCP 调试日志改为条件输出，减少生产环境日志噪音。

其他：备案号链接到工信部备案系统。

2025.11.24 工作记录

多模型适配：提取 DeepSeek 思考过程，优化思考内容提取的模型适配逻辑。

Schema 修复：修复 OpenRouter/xAI 调用时的 JSON Schema 格式错误；修正 `site_overview_provider` 和 `site_overview_stats` 的空 properties 编码问题。

性能优化：释放 Session 锁，防止长连接阻塞用户浏览其他页面。

提示词优化：润色和优化系统提示词。

2025.11.23 工作记录

成本控制：增加中断机制，防止 LLM 调用产生昂贵费用。

后端工具完善：优化 registry.py 和 core_tools.py 的逻辑。

2025.11.22 工作记录

代码架构优化：拆分 `wordpress-ai-agent.php` 和 `agent-fox-client.js` 为模块化结构，提高可维护性。

工具管理改进：新增后台工具管理页面，支持启用/禁用可用工具；将 supply 类工具包装为内部工具，不向 LLM 公开。

性能优化：在 PHP 层添加缓存机制解决 core tools 频繁刷新问题。

Bug 修复：修复聊天记录的数据库连接问题，简化冗余配置选项。

工具命名优化：统一优化各工具的命名规范。

2025.11.21 工作记录

已知问题：core_semantic_search / core_recommend_related 的权限有问题，管理员登录也搜不到私密内容。（待修复）

2025.11.20 趁着Gemin3发布，激动得通宵了两晚，疯狂用来改博客。确实好用很多，还淘宝买了一年gemini pro，里面有个上传github仓库的功能，省了我很多买api tokens的钱。

2025.11.20 工作记录

• 工具集重构：重构八大核心工具，提取公共函数，并将搜索工具优化更名为 smart_content_discovery。
• 新增 Mention 功能：完善了 @mention 机制的文件结构，并将其集成到 post-ai-chat 模块中。
• 客户端体验优化：实现了 AI 对话的平滑输出与滚动，并新增了“中断回答”按钮。
• UI 样式美化：美化了相关文章卡片、目录及 AI 对话框样式，修复了顶栏与 Sidebar 的重叠问题。
• 安全性修复：修复了 get_post_chunk 工具可越权读取私密文章的安全漏洞。
• Bug 修复：修复了访客气泡遮挡输入框、Loading 动画异常及分类统计包含私密文章的问题。

2025.11.19 工作记录

• 代码清理与解耦：清理冗余代码，对 CSS 样式、相关文章及验证码功能进行了模块化解耦。
• 架构迁移与重构：将自定义 MCP 工具迁移至主插件，并对 Python FastAPI 服务端进行了模块化。
• 机制改进：将摘要向量的更新机制改为 WP-Cron 异步任务，优化了相关文章设置页的交互。
• 样式重构与对齐：将 SCSS 文件与原 CSS 对齐，美化了后台管理页面及移动端导航栏体验。
• 核心修复：修复了 post-ai-chat 的对话记忆失效问题以及相关文章推荐逻辑。

2025.11.16 get_post_chunk工具新增 meta_only 模式，可仅返回文章元信息，包括 post_id、title、url、excerpt（含 public/private 权限逻辑）、date/date_gmt、modified/modified_gmt、author、category、tags、comment_count、post_type、status 等；同时统一摘要处理逻辑，优先解析结构化摘要标签并按权限选择，无结构化摘要时自动回退正文前 500 字。

2025.11.16 修复了post_discovery_search和list_archives这两个工具中原本错误的Excerpt字段fallback逻辑，原来总是从正文开头截取，现在能够正确根据登录状态从post_excerpt字段解析了，如果没有结构化摘要，才从正文开头按字数截取。

2025.11.15 Langchain有个ReAct最多调用25轮的默认限制（工具调用和接受回答算两次，实际上最多12次工具调用），现在手动设置了config = {“recursion_limit”: 50}，提高限制到两倍了。

2025.11.14 修复了get_post_chunk返回“API空响应”的问题。之前用GPT-5 thinking好久都没解决，今天用GPT5.1-think思考了4分半一次性改成功了。错误原因是分chunk时破坏了多字节字符，导致边界处UTF-8编码不完整而异常。

2025.11.13 给AI excerpt后台增加了一个根据文章id手动触发摘要重新生成并索引的按钮。

2025.11.8 bug记录，list_archives工具中，返回的excerpt总是用截取文章正文前50字的方法（经检验，AI摘要确实生成了，但是工具中仍然获取的是前50字符，没有用excerpt字段存储的AI摘要），没有用AI生成的总结性摘要，导致判断文章语意可能不准确，要修改。

2025.11.4 把Agent-fox-client也迁移到wordpress-ai-agent插件了，过程中，发现get_post_chunk工具对于一些从知乎粘贴过来的文章会因为UTF-8解析等原因返回API空响应，还没有解决这个问题。另一个bug是mention文章那里，左边还有下拉表的下半边，鼠标不是光标，无法点击输入。还有一个bug是，[“agent-fox-secret”]短代码包裹的内容，只有在mcp tools比如get_post_chunk搜索结果中是直接可见的，并不会渲染成预期隐私功能。（我花了24h搞这个东西了，我觉得11月停更了，太耽误时间了，昨晚直接通宵了，一开始ai coding就停不下来了，对着bug越想越气就是不想睡）

2025.11.4 给vector-connector加了一个简单的仪表盘，可以删除某一条具体的向量数据了

2025.11.3 开始尝试整合零散的插件，新建了一个wordpress-ai-agent主插件，今天把ai-excerpt-generator和post-ai-chat和core-llm-manager和fastapi-vector-service整合进去了，不过还没有完全测试所有细节上的功能是否成功迁移了。

2025.9.22 新增了访客统计插件，下一步可以将统计数据整合到小狐的统计工具里去。另外，AI-excerpt有时自动生成失败会返回全文，这个bug要改改，LLM失败应该回退到原文前50个字。

2025.9.19 bug解决：

问题: AI-Excerpt插件开启后，文章中的HTML标签被意外剥离。
原因: 插件使用WP-Cron在后台更新文章。Cron任务在没有用户身份的上下文中运行，导致unfiltered_html权限检查失败，从而触发了WordPress核心的KSES安全过滤机制。
解决: 在Cron处理函数中，于调用wp_update_post之前临时移除KSES过滤器，更新完成后立即重新添加，确保在不牺牲网站整体安全性的前提下保留摘要的HTML格式。

2025.9.16 性能优化：keyword_snippet_search的返回结果只按照返回的term组织的，每个term会附加所在文章的meta信息，当同一篇文章内部多个结果被匹配时，会重复出现文章meta信息，造成信息混乱和上下文大幅浪费。现在在每一个分页内部对来自同一篇文章的检索结果做了合并处理，只返回一次meta信息。同时，对wordpress和内联css等html标签做了更加精细的过滤，删除了与内容无关的格式信息，尽量把html标签向markdown转换。

2025.9.16 成本优化：因为我的embedding模型是dashscope调用API，每次都会花钱，尤其加了上一条自动文章推荐之后，就十分害怕被大规模爬虫什么的，带来巨额API费用。所以就想，要不要把所有固定的文章摘要的向量缓存起来。后来再一想，可以不仅仅是摘要，所有需要embedding的都可以缓存啊，我的大头成本根本不是excerpt，而是保存文章时，每次都会全文分块，每个chunk都要重新embedding。原来想过从wordpress客户端进行增量更新，但觉得太麻烦暂时放弃了。这次思路打开了，完全可以从fastapi-vector-service这边后端入手啊。只要查询过的就从后端缓存调用。这样wordpress客户端的就不用处理任何去重和增量更新，一股脑请求就行了。

全局缓存：现在，无论是文章全文的段落，还是文章的摘要，在被计算嵌入向量之前，都会通过一个基于其内容哈希的全局缓存进行检查。极致的成本节约：只有当一段全新的、或被修改过的文本出现时，系统才会调用 text-embedding-v4 API。对于所有未改变的内容，其向量将直接从内存缓存中读取，API 调用成本接近于零。智能增量更新：当你更新一篇文章时，只有内容被修改的段落会触发新的 API 调用。未变动的段落会因为哈希值不变而命中缓存，极大地降低了更新文章时的开销。架构简化：此方案无需在 WordPress 和 FastAPI 之间建立复杂的缓存清理通知机制。实时相关性：由于向量查询（ChromaDB.query）依然是实时执行的，所以即使用了缓存，相关文章推荐的结果也总是最新的。缓存持久化：所有的嵌入向量缓存现在都会被写入到项目目录下的一个 embedding_cache 文件夹中。即使你重启 FastAPI 服务，缓存依然存在，避免了冷启动时产生不必要的 API 调用。全自动运行：此方案依然利用内容哈希作为缓存键，无需任何手动干预或清理。当文章内容更新时，新的向量会自动计算并缓存。当缓存大小达到 1GB 后，系统会自动删除10%的最长时间未被使用的缓存条目，为新数据腾出空间。

2025.9.16 重用了本来给小狐准备的post_discovery_search，当每篇文章打开时，自动（Ajax异步）调用其中的related post查询功能，通过摘要的向量相似度匹配“相关文章”，替换掉了原来评论区上方“上一篇 下一篇”模块（反正也没啥用）。现在，这个相关文章推荐我非常满意，因为它全自动，不用手动维护，而且完全依靠语意，推荐相当精准。而且本来只是给小狐的工具，现在一石二鸟了，很爽。

2025.9.16 性能优化：

问题描述：因为之前设置了每次save_post时，FastAPI-vector-connector触发重新对文章embedding并入向量库，而且AI-Excerpt-generator也触发自动调用LLM重新生成摘要。这两项（尤其是后者）导致“保存”这个动作需要长达半分钟的时间，严重拖慢速度。

解决方案：现在，所有流程都已串联并实现了异步处理：

• 全文向量自动更新：文章内容的任何变动（包括摘要的更新）保存后，都会触发后台任务来更新全文的段落向量。
• 编辑器无卡顿：保存文章时，向量化和摘要生成任务都会被推到后台执行，编辑器界面会立刻响应。
• 向量自动清理：删除文章时，其在向量数据库中的所有数据（全文和摘要）都会被自动清理。
• 摘要向量自动更新：当后台任务成功生成并保存了新的摘要后，会自动触发一个异步请求，将这个新摘要更新到向量数据库中。

2025.9.16 新增了用于评论检索的工具comment_query。

2025.9.15 下线了list_posts_by_tag和list_posts_by_category两个工具，将其功能合并到list_archives作为上位代替：

‘用途：按分类(category)/标签(tag)/日期(date_after/date_before)获取已发布文章列表；固定 date DESC 排序与每页 20 条；支持分页（page）。’,
‘返回：items(含 post_id/title/permalink/categories/tags/excerpt/date/modified/comment_count)，以及分页/提示信息（has_more/next_page/tips）。’,
‘说明：category/tag 可为 ID、slug 或名称（或其数组）；date_* 为 YYYY-MM-DD；page 从 1 开始。’

list_archives工具设定

不过，这样一来就跟post_discovery_search功能有些重叠了。post_discovery_search做调整：探索/发现（只保留 related 与 random 两种模式）。不再承担“按时间/分类列清单”的职责。收紧 post_discovery_search 的 schema（去掉 latest，避免与list_archives重叠）。

2025.9.15 因为现有工具已经足够强大，在后端移除了“自动获取@mention的文章”的逻辑，改为只在前端显示列表，让LLM自己去调用工具阅读。放大了get_post_chunk的分片字数限制到20000（原来5000，原因是langchain默认25次调用不输出回答就掐死，对于很长的文章，往往不够获取全文）。

2025.9.15 为了解决“多数时候只有文章标题而非 ID”的现实场景（因为工具结果是不会保存在对话历史记录的，即便LLM上一步获取过id，但只要它回复中没有出现，就遗忘了。但是文章标题它总会说出来），我把 post_chunk_by_id 升级为更通用的 get_post_chunk，支持 by_id / by_title / by_url 三种定位方式；并内置简单的消歧策略。这样 LLM 即使只有标题也能一跳到位拿上下文分片。唯一命中 → 返回 { chunk, post_id, title, offset, has_more }。 多个命中且无法唯一确定 → 返回 candidates（含 post_id/title/date/category/tags/url），并给出 reason: “ambiguous”；由上层 LLM 追加消歧条件后再次调用。 未命中 → 返回 reason: “not_found”。为什么这样最稳 对齐真实调用场景：列表页/检索结果经常只有标题 + 链接，不暴露 ID。 降低出错率：显式 locator_type 让 LLM 清楚“我现在用的是标题还是 ID”。 简洁的消歧：常见歧义（同名文章、系列文）可用 category/tag/日期 配合 prefer_recent 一步解决；复杂场景再走二次调用即可。

2025.9.14 将get_related_posts工具完全融入了get_recommend_posts工具，并将后者升级为multi_mode_post_search，支持三种模式（最新、随机、相关）的文章检索，同时正交地支持三种过滤方式（按照标签、按照分类、按照日期(通过data_before和date_after参数）。合并后，删除了get_related_posts工具以减少工具冗余。

发现工具多了以后（现在有9个）LLM总不能精准的选到最合适的工具，可能是我为了省事非要把工具名称弄得很“标准化”，这样反而容易引起选择困难。让GPT老师微调了一些工具名称和工具描述，同时在系统提示词新增了一些工具搭配建议。

• get_content_by_keyword → keyword_snippet_search
• get_content_by_vector_search → semantic_post_search
• get_post_content_by_id → post_chunk_by_id
• get_posts_by_category → list_posts_by_category
• get_posts_by_tag → list_posts_by_tag
• get_site_stats → site_overview_stats
• list_all_categories → list_all_categories（保留）
• list_all_tags → list_all_tags（保留）
• multi_mode_post_search → post_discovery_search

说明：名称统一采用“动词+对象(+方式)”的风格；看到名字即可判断“能做什么、返回什么”。

GPT-5

新建了get_related_posts工具，在fastapi-vector-service新建了一个excerpt的collection，同时新增了对文章的excerpt进行embedding并入库，以及专门从excerpt向量库中查询并返回相关文章的api端点。同步修改了AI-excerpt-generation插件，使其可以调用fastapi-vector-service新增的api端点，当检测到文章excerpt字段改动时自动刷新向量库，同时在后台设置了“一键全站摘要向量化”的按钮。利用上面两项基础设施，在Eamon-custom-mcp-tools新增了get_related_posts函数，可以查询文章id或关键词、关键句的最相关摘要。

2025.9.13 重构了post-ai-chat插件，原先是插件内部同时实现前后端，通过core-llm-manager（相当于实际的后端）进行与LLM的通讯，只在post-ai-chat插件内部实现request的拼接和response的接收。同时也承担了一部分设置LLM的温度、max_tokens、速率限制等参数控制。现在，完全将post-ai-chat升级到以Langchain-agent-fox为后端了（现在是名副其实的小狐分狐了），与agent-fox-client现在共享一个后端服务，post-ai-chat也变成拥有mcp tools的ReAct架构了，删除了至少70%的原有弃用代码，但保留了调用WP原生函数从数据库直接获取当前文章的meta, content, comments等背景信息的功能（这部分其实还是后端解决的，代码在后端，“保留”说的是功能）。用户体验上，post-ai-chat因为有了工具更加智能了，代价是首次输出会慢不少，因为现在需要和后端建立通讯和初始化了。

两个client现在基本上是平行的，从Eamon_custom_mcp_tools这个tools pool获取所需的工具，组装自己的tools set。今后的开发方向就是单独为post-ai-chat配置更多的服务于“单篇文章解析”的工具了，比如推荐关联文章、mermaid图渲染、python解释器（不过这个贼危险，可能会有注入攻击风险，我最近被黑客连续三天控制电脑，现在网络安全意识强的一批，笑死）等等。

在前端显示方面也有升级了，优化了tool_call的显示，原来是个特别丑的黑色容器、白色文字背景、红色字体。现在优化了配色、并设计地更加紧凑静置了。另一个优化是原先小狐回答中的一些svg符号会在chunk输出的时候不停的闪烁，现在更加稳定了。同时，让单个chunk内部的文字以“单字“的精度逐字输出了（间隔30ms，感觉还可以放大一点，因为网速不好chunk本身吐得慢），这样出字就更加平滑好看了。

另外一点是，core-llm-manager现在可能用处不大了，原先想的是这些所有涉及LLM的服务都通过它来与LLM交互，我曾经费了特别多的时间，为deepseek, doubao, gemini, aliyun, zhipu等每一个LLM provider根据格式的不同配置了不同的request和response建构和解析函数，所以我现在舍不得删掉它。post-ai-chat原先是core-llm-manager最主要的服务对象。毕竟是个基础设施，保留着吧（好像AI-excerpt目前还在依赖core-llm-manager，我记不清了）。

2025.9.12 现在每篇文章点开都有小狐自动跳出来读摘要啦！设计了AI自动和手写两种方式，可以在文章编辑页面右侧底部进行手动选择交给AI还是手写。如果交给AI，会在每次新建或修改的文章“保存”时自动触发LLM生成面向public和private的两份摘要。就是要注意，手写摘要必须要和自动摘要满足相同的public/private两层的格式，不然一些根据权限调用不同摘要的MCP tools会受到影响。

2025.9.8 在eamon-content-protection插件新增了一个功能，当遇到以下短代码可以创建仅AI Agent可见的内容：

[agent_fox_secret]仅Agent-Fox可见的秘密内容[/agent_fox_secret]

适用于向AI提供额外上下文信息，前端完全隐藏，普通用户看不到任何内容。而AI Agent（如Agent-Fox）可以通过get_post()->post_content获取内容。

同时添加提示词配合：

for visitors: – **机密信息处理**：哼，小狐才不会轻易透露秘密呢！遇到 `` 标记的内容，小狐会好好消化理解，然后用小狐自己的话重新表达，才不会把原文直接甩出来呢！这些可都是内部参考资料，小狐会用来提供更贴心的回答~”
for eamon: – **机密信息处理**：主人~ 小狐遇到 `` 标记的秘密信息时，会乖乖地消化吸收，然后用小狐的理解重新表达给您！这些可都是内部参考资料，小狐会用来给您提供更准确有用的回答，但绝对不会把原文直接泄露出去的~ 小狐最懂怎么保护秘密了！”

2025.9.2 增加了对访客模式的系统提示词的保护。（反正我自己试了半天攻不破）

2025.9.2 我终于搞懂了莫名其妙的删除线来自哪里。小狐撒娇时总爱用“~~”结尾，连续两个放在一起就正好是md的删除线“这段文字会显示成删除线”。现在在md渲染代码里禁用这个语法了（因为是调用marked.js库解析markdown的，不好拆开，所以先让它解析，然后后处理删除<del>标签，反正一般也不会输出有意识的删除线）。

2025.9.2 我有一些带音乐播放器的文章，get_post_by_id总是读到一大坨html代码。现在，该工具内置了clean_gutenberg_html_blocks()函数，可以对post-content的结果预处理，去除掉<!–wp:html–>区块里面的<scripts>和<style>标签。

2025.9.1 Agent-Fox 智能助手现已支持文章引用功能。用户只需在输入框中输入@符号，即可快速浏览和引用网站中的任何文章。系统会自动为AI助手提供完整的文章上下文，使回答更加精准和相关。此功能支持键盘导航和实时搜索，大大提升了用户与AI助手的交互效率。

2025.9.1 动态地直接将所有tags和categories的id和name硬编码在了get_recommend_posts, get_posts_by_tag, get_posts_by_categories三个工具中，这样就不需要在很多情景下优先调用list_all_tags和list_all_categories工具了。不过后两者也保留了，他们返回的信息更加完整，任务更加明确。

2025.9.1 将get-recent-posts工具替换成get-recommend-posts工具，内容进行了扩展，不仅能返回最新文章，也能通过input参数查询随机文章，还可以按照标签或分类筛选。（今天尝试把deepseek换成grok-code-fast-1，觉得，哪里都对，就是语气说不上来的难受和奇怪。说中文的本事还是得deepseek）

2025.9.1 解决了md渲染导致的删除线问题，以及颜文字的渲染问题。重拍了工具和文字的渲染顺序（原来是工具统一放在回复的开头，现在是实际的调用和回复顺序了）//有一说一，grok-code-fast-1对我的钱包太友好了，功德无量啊！

2025.8.29 让GPT老师给小狐所有的MCP tools都调整了工具使用说明和input schema的参数说明。重点加入了推荐各个工具之间相互配合的提示文字。

2025.8.29 改进了get_posts_by_keyword的打分算法。主要是位置加权（标题 > 摘要 > 正文 > 评论），频次做对数压缩（避免长文刷分）。

2025.8.29 新建了AI_excerpt插件，可以调用core-llm-manager的LLM调用接口和llm-data-bridge的隐私内容过滤接口。自动生成[public_excerpt][/public_excerpt]和[private_excerpt][/private_excerpt]两类摘要。然后发现，原生搜索结果页面会显示全部（也就是两部分）摘要。于是又加了个mu-plugins来login-aware-excerpt.php根据登录状态剔除另一部分。

2025.8.28 将get_content_by_keyword升级为支持AND, OR, NOT三种逻辑运算的布尔搜索，结果全部召回，并统一进行去重和打分排序。

2025.8.28 修复了因为html代码乱入导致的DOM结构混乱的bug。在前端修复 escapeHtml 转义函数，确保 &, <, >, ", ' 都被正确转义；在 mdToHtml 里对模型输出的 Markdown 先把 < 和 > 全部转义，再交给 marked.parse 渲染，这样可以继续正常解析 []() 链接、粗体、列表等 Markdown 语法，同时禁止模型注入任何原始 HTML，从而避免结构破坏和样式污染；如果模型输出 HTML 代码，会被安全地展示为文本，而不会被当成真正的 DOM 渲染。

2025.8.28 将 get_posts_by_keyword 改造为了一个功能强大的新工具 get_content_by_keyword。这个新工具的核心功能是：根据用户提供的关键词，在所有授权访问的文章（包括私密和受密码保护的内容）中进行搜索。它不会返回整篇文章，而是以关键词为中心，提取并展示前后50个字符的文本片段。为了确保结果的有效性，所有返回的片段会首先按照其所在文章的匹配总数进行相关性排序，确保最相关的文章内容优先显示。同时，为了避免返回结果过长，该工具还内置了分页功能，将所有找到的文本片段进行分页，并在返回结果中提供清晰的摘要信息，如“从X篇文章中找到Y个匹配，当前显示第A页，共B页”，方便进行后续的翻页查询。此外，每个片段都包含了精确的字节偏移量（start），可以无缝配合 get_post_content_by_id 工具，直接从该位置读取文章的完整内容。

2025.8.27 彻底重构了，放弃了deep research的复杂多Agent方案，简简单单，单一LLM + MCP tools，ReAct架构。目前实现了九个工具。

内容检索工具: get_content_by_vector_search (语义搜索), get_posts_by_keyword (关键词搜索), get_posts_by_tag (标签浏览), get_posts_by_category (分类浏览)
内容导航工具: get_recent_posts (获取最新文章), get_site_stats (站点统计), get_post_content_by_id (完整文章阅读)
内容探索工具: list_all_tags (标签目录), list_all_categories (分类目录)

贵啊，Claude真贵啊！我今天一天往OpenRouter充了五六次，花了得有五六百块钱。

改进方向：1, 把摘要从粗暴截断改成LLM总结，2, get_posts_by_keyword返回含有该关键词的文段而非关键词所在文章的摘要

2025.7.15 bug记录：

1. 向量库屏蔽没有做好，目前私密文章过滤掉了，但是密码保护的文章可以被向量库索引到，应该添加硬过滤。同时，如果一篇文章已经出现在向量库中，当公开状态变为私密或密码保护时，也应当执行从向量库清空的处理。等下，更好的逻辑应该是，向量库不过滤。只是索引的时候添加过滤选项，通过返回文段的meta信息过滤。这样，已登录用户还是可以享受到私密和密码保护文章的向量检索。
2. 现在的迭代逻辑太简陋，下一步改进方向应该让第一步查询变成检索方案规划，然后调用多个LLM并发执行第一步规划的检索任务。最后再汇总。执行下一轮的“规划→执行”。最终一步汇总成最终答案回复用户。
3. 但是这样一来上下文就太太太长了，所以在每一步执行结束之后应该再加一步内容压缩。因为检索回来的结果肯定没用的居多。内容压缩的逻辑应该是逐一判断每个文段是否与检索词相关，不相关就丢弃，对于相关的文段，也应当进一步提取这一段中具体哪几句话跟检索词相关，其他句子也删掉。由于是逐个文段判断，这一步也应该并发调用LLM，但应该手动限制并发数量，比如zhipu api最大并发数是30。同时用速度快的flash模型。
4. 规划→并发执行→并发内容压缩→汇总→第二轮规划→并发执行→并发内容压缩→汇总→第三轮规划……
5. 每一次“规划任务”的上下文应当包括每一次迭代的“汇总”信息。可以把这个整合步骤放在每一轮“汇总”阶段，直接跟上一轮的汇总文本合并。这时还应当加一步去重操作，这个不用调用LLM，因为向量库返回的文段是固定的，可以直接Python过滤掉。
6. 另外我发现，几乎很少会用到关键词匹配，关键词能查到的内容，向量查询也能。而且如果用原生wordpress的关键词查询只能返回整篇文章或摘要，不能具体到段落，跟向量查询融合的不好。非要用关键词匹配的话，需要在向量库api里加一个端点直接从向量库而不是Mysql数据库查询。这样可以规范返回的格式。
7. 还有一个问题是需不需要专门写入中间信息到文件，目前感觉存在python变量就够用了。

{
  "plan_reasoning": "当前信息已确认博主与'宋同学'有关，但关系细节不足。下一步需深入挖掘'宋同学'的具体事迹并探索博主的其他社交圈。",
  "tasks": [
    {
      "task_id": "task_001",
      "query": "宋同学",
      "tool": "search_posts_by_content",
      "description": "精确查找所有提及'宋同学'的段落。"
    },
    {
      "task_id": "task_002",
      "query": "博主的朋友圈、同事、家人",
      "tool": "semantic_vector_search",
      "description": "模糊搜索与博主社交网络相关的文章。"
    },
    {
      "task_id": "task_003",
      "query": "聚会 OR 合作 OR 交流",
      "tool": "search_posts_by_content",
      "description": "关键词搜索描述社交活动场景的段落。"
    }
  ]
}

{
  "plan_reasoning": "当前信息已确认博主与'宋同学'有关，但关系细节不足。下一步需深入挖掘'宋同学'的具体事迹并探索博主的其他社交圈。",
  "tasks": [
    {
      "task_id": "task_001",
      "query": "宋同学",
      "tool": "search_posts_by_content",
      "description": "精确查找所有提及'宋同学'的段落。"
    },
    {
      "task_id": "task_002",
      "query": "博主的朋友圈、同事、家人",
      "tool": "semantic_vector_search",
      "description": "模糊搜索与博主社交网络相关的文章。"
    },
    {
      "task_id": "task_003",
      "query": "聚会 OR 合作 OR 交流",
      "tool": "search_posts_by_content",
      "description": "关键词搜索描述社交活动场景的段落。"
    }
  ]
}

用户的原始问题是：'博主的社会关系'
当前正在处理的任务是：'查找博主提到的朋友姓名'

--- 文档内容开始 ---
{单个文档片段的文本}
--- 文档内容结束 ---

请判断以上文档内容是否与当前任务'查找博主提到的朋友姓名'直接相关？
请只回答 "相关" 或 "不相关"。

用户的原始问题是：'博主的社会关系'
当前正在处理的任务是：'查找博主提到的朋友姓名'

--- 文档内容开始 ---
{单个文档片段的文本}
--- 文档内容结束 ---

请判断以上文档内容是否与当前任务'查找博主提到的朋友姓名'直接相关？
请只回答 "相关" 或 "不相关"。

用户的问题是：'博主的社会关系'

通过搜索，我收集到了以下高度相关的信息片段：
[
    "从《与宋同学的毕业告别谈话》中提取的片段...",
    "从《三观》中提取的片段...",
    "从另一篇文章中提取的片段..."
]

请基于以上信息，生成一个全面、准确的回答。

用户的问题是：'博主的社会关系'

通过搜索，我收集到了以下高度相关的信息片段：
[
    "从《与宋同学的毕业告别谈话》中提取的片段...",
    "从《三观》中提取的片段...",
    "从另一篇文章中提取的片段..."
]

请基于以上信息，生成一个全面、准确的回答。