TaiXu-Admin V0.1.3 的更新重点，不只是增加一个 Agent 功能，而是把 LLM、RAG、任务规划、知识库重构和历史记忆管理进一步组织成一套可落地的 AI 技术系统。此次版本实现了具备复杂度分析、意图分析与任务规划能力的 Harness Agent，同时改进了 LLM Wiki 解析、搜索、自定义知识库重构，以及 RAG 和 Agent 的异常处理。
Harness Agent 解决什么问题
简单的“用户问题 -> LLM 回答”适合问答场景，但遇到多步骤任务时，系统需要先判断问题复杂度，再识别用户意图，最后拆解任务并决定是否调用检索、工具或后续 Agent。
V0.1.3 的 Harness Agent 可以理解为一个任务编排层，核心流程大致如下：
- 分析问题复杂度，区分直接回答和多步骤任务。
- 识别用户意图，例如查询文档、重构知识、总结历史信息或执行操作。
- 生成任务计划，把复杂请求拆成多个可执行步骤。
- 根据计划调用 RAG、知识库或其他 Agent。
- 汇总结果，并在异常时返回可识别、可处理的错误信息。
这类设计的价值在于，模型不再单独承担所有决策。复杂度分析和任务规划可以把不稳定的自由生成，约束为更明确的执行流程。
LLM Wiki 与知识库的变化
版本更新包含 LLM Wiki 解析及搜索能力，同时增加知识库的 LLM Wiki 自定义重构。这说明知识库处理链路开始从“导入文本并切分”向“理解文档结构并重构内容”演进。
在实际项目中，原始 Wiki 往往包含目录、重复说明、代码片段、版本差异和无效导航。直接向量化全部文本，会让检索结果变得嘈杂。可以这样实践：
- 解析标题层级，保留文档的章节关系。
- 清理导航、重复页脚和无意义的格式标记。
- 将代码示例、配置项和正文分别保存元数据。
- 为每个知识块记录来源、版本、路径和更新时间。
- 检索时同时使用语义相似度与关键词过滤。
LLM 自定义重构适合处理结构不统一的 Wiki，但也需要保留原文和重构结果，避免模型改写造成事实丢失。知识库重构应当可追踪、可回滚，而不是直接覆盖原始数据。
一个可改造的任务规划示例
下面是一个不依赖外部模型服务的最小 Python 示例，用来演示 Harness Agent 的基本编排思路。它可以直接运行，也可以把 analyze_intent 和 build_plan 替换成实际的 LLM 调用。
运行方式：将代码保存为 harness_agent.py，执行 python harness_agent.py。
from dataclasses import dataclass
from typing import List
@dataclass
class Task:
name: str
action: str
def analyze_intent(question: str) -> str:
"""实际项目中可替换为 LLM 的结构化意图分析。"""
if any(word in question for word in ("搜索", "查询", "文档", "Wiki")):
return "knowledge_search"
if any(word in question for word in ("重构", "整理", "改写")):
return "knowledge_rewrite"
return "general_question"
def build_plan(question: str, intent: str) -> List[Task]:
if intent == "knowledge_search":
return [
Task("检索知识库", "rag.search"),
Task("整理证据", "llm.summarize"),
]
if intent == "knowledge_rewrite":
return [
Task("读取原始 Wiki", "wiki.load"),
Task("重构文档结构", "llm.rewrite"),
Task("保存版本记录", "knowledge.publish"),
]
return [Task("直接回答", "llm.answer")]
def run(question: str) -> None:
complexity = "complex" if len(question) > 30 else "simple"
intent = analyze_intent(question)
plan = build_plan(question, intent)
print({
"question": question,
"complexity": complexity,
"intent": intent,
"plan": [task.__dict__ for task in plan],
})
if __name__ == "__main__":
run("搜索 Wiki 中关于 RAG 异常处理的文档，并整理出升级建议")
生产环境中，计划结果最好使用固定 JSON Schema 校验，例如要求每个任务包含 name、action、input 和 timeout。这样可以在执行前拦截缺少参数、未知工具或超时配置，避免 Agent 生成不可执行的计划。
记忆与异常处理不能被忽略
历史记忆管理更新，通常意味着系统需要重新考虑“哪些内容应该被记住”和“记忆如何参与当前任务”。对长对话或连续技术问答来说，建议区分以下几类信息：
- 短期上下文：当前会话中的最近消息。
- 用户偏好：稳定、低频变化的回答偏好或技术栈信息。
- 任务状态：当前计划已完成的步骤和待处理步骤。
- 长期知识：经过审核后进入知识库的内容。
不要把所有历史消息原样塞回提示词。这样会增加上下文成本，也可能把过期结论带入新任务。记忆写入应当有来源、时间和置信度，重要结论最好经过摘要或人工确认。
RAG 和 Agent 的异常处理同样需要独立设计。至少应覆盖：
- 检索服务不可用或超时。
- 检索结果为空。
- LLM 返回格式不符合计划 Schema。
- 工具调用失败或重复调用。
- 任务执行超过最大步数。
- 重构结果无法通过内容校验。
错误信息应区分用户可见消息与内部诊断信息。用户看到“知识库暂时不可用”即可，日志中则应记录请求 ID、任务步骤、工具名称、耗时和原始异常，便于定位问题。
采用时的检查清单
TaiXu-Admin V0.1.3 更适合作为 AI 应用技术系统的参考和集成基础。接入类似架构时，可以重点检查：
- 是否能区分简单问答与复杂任务。
- Agent 计划是否经过 Schema 校验和步数限制。
- Wiki 原文、重构版本和发布记录是否独立保存。
- RAG 结果是否带有来源和版本信息。
- 历史记忆是否有明确的生命周期。
- 外部模型、向量库和工具调用是否具备超时、重试和降级策略。
- 是否记录每一步 Agent 决策，方便评估回答质量。
这次版本更新传递出的信号很明确：LLM 应用的工程重点正在从单次生成，转向知识处理、任务编排、记忆管理和异常恢复。真正决定系统能否稳定运行的，不只是模型能力，还包括围绕模型建立的可观察、可校验和可回滚机制。