Agent 专题

基础

问题：agent 范式

Prompt + LLM + Output Parser（最基础）

ReAct（推理 + 行动 + 观察）

Tool calling（工具调用）

Plan-and-Execute（规划 + 执行）

Multi-Agent（多智能体协作）

问题：记忆系统一般怎么设计

仿人类记忆 短期记忆，最近的对话上下文 长期记忆，用户画像、历史经验

问题：怎么实现跨对话记忆

问题：MCP是什么

模型上下文协议， 是模型连接外部api 的开源标准

问题：skills 是什么

简单说就是技能，把做一件事的步骤打包，避免模型犯错

问题：agent 有哪些怒分

感知层：处理用户输入 推理引擎：根本能力 记忆系统： 工具：外部世界操作 编排与状态管理

问题：怎么消除工具调用幻觉

结构约束：强制定义schema 执行校验：系统要校验工具是否真的执行 反馈闭环：如果模型调用错了，系统得反馈给模型

问题：工具 description 怎么写

用途、边界、参数、反向场景

问题：agent 怎么评估

一般从基础模型能力、流程控制的token消耗、安全策略、进化能力

问题：怎么设计 agent 失败续跑

关键是怎么发现agent错了 模型的错误很难观测，并不像传统程序一样直接报error 一般有 死循环：反复调用同一工具 方向偏离：在错误的路上越走越远 上下文溢出：多轮循环后已经忘了最开始的任务是什么

要对不同的情况具体处理 工具调用和每一步的输出检测，如果一直没有进步就触发中断 对于方向偏离，每隔几步审视方向，是否偏离了最初的任务 上下文溢出则要进行上下文管理，在某一阶段触发摘要

设置检查点，从检查点回滚重试

兜底策略，有些失败没必要重试，触发人工

显示失败直接把报错信息发给llm，自己纠正

Agent 失败续跑的核心是把执行过程拆成有状态的 step，每一步都做 checkpoint 存储，然后失败后可以从最近成功的 step 恢复继续执行，同时配合 retry、幂等设计和 fallback 机制，避免重复执行或状态污染。在工程上一般会用 LangGraph 这种 graph-based agent 来实现，因为它天然支持 state + checkpoint + resume

本质上就是把 Agent 从“无状态对话系统”升级成“可恢复的分布式工作流系统”。

问题：agent的规划、执行、反思闭环如何实现

planner 拆任务 executor 执行 reflector 校验

必须具备 最大轮次、超时控制、失败原因记录、人工兜底

问题：多轮对话中，记忆如何分级管理？缓存策略怎么设计

短期记忆：上下文 会话记忆：摘要 长期记忆：用户画像 业务知识：知识库

问题：agent 推理链路包含多个串行工具，延时高，怎么优化

先拆链路，看延时瓶颈 能并行并行 能缓存缓存

复杂决策用大模型，简单场景用小模型

加超时、异步任务、流式返回等

问题：agent系统的核心监控指标有哪些

成功率、工具调用失败率、重试次数、幻觉率、token成本、人工接管率、延迟

问题：多 Agent 状态机编排 怎么设计的

我们现在的设计没有用 LangGraph 这种现成框架，而是自己搭了两层：PocketFlow + Temporal。

为什么不用 LangGraph：

评标任务有几个 LangGraph 覆盖不了的需求：单个评审流程可能跑几小时甚至跨天，Worker 宕了要能自动恢复（Temporal 的断点续跑）；中间需要插入专家确认的人工节点（Signal 机制）；Activity 级别要有精细的重试策略和超时控制；每一步的执行历史要完整保留，可以回溯"当时发生了什么"。LangGraph 的设计偏单进程、内存态，这些它给不了。

第一层：PocketFlow（轻量级状态机，管单机内的小流程）

自己写的，就 100 行代码。核心是 Node 三段式生命周期：

• prep：准备输入
• exec：执行逻辑（调 LLM 或计算）
• post：把结果写回上下文

然后用 >> 运算符串联。财务评标这类不走数据库的纯计算流程，我们用 PocketFlow 编排了 7 个 Agent：要点提取 → 财报抽取 → 合规审查 → 数据提取 → 代码生成 → 代码执行 → 评分解释。其中财报抽取和合规审查可以并行跑多家公司。

第二层：Temporal（持久化工作流引擎，管跨服务的长流程）

评标主流程全程跑 Temporal。每个评标步骤是一个 Activity，整个流程是一个 Workflow。Stage 之间靠 Temporal 编排保证顺序。

具体实现上用了几个关键的 Temporal 模式：

1. Child Workflow 做阶段拆分。技术评审拆成 5 个独立阶段：生成要点 → KV 提取 → 生成分析 → 生成排名 → 生成评分。每个阶段是一个 Child Workflow，后一个必须等前一个确认完才能开始。

2. 并行 Fan-Out + 分批控制。KV 提取这类"每个投标人 × 每个评审要点"的笛卡尔积任务，做了并行执行，但加了可配置的并行度控制（默认 5），避免打爆下游服务。每个批次的失败不影响其他批次，最终汇总成成功/失败计数。

3. Signal 实现人工介入。专家确认要点时，Workflow 执行到 await workflow.wait_condition()，等前端发 Signal 过来。超时 1 天没确认就报错。确认后 Workflow 自动继续。也支持"自动确认模式"——客户要求全自动时直接过，不等人工。

4. 确定性约束倒逼架构。Temporal 要求 Workflow 必须确定性——不能用 datetime.now()、随机数、UUID。所有外部 I/O（DB、LLM、文件）都封在 Activity 里。这个约束虽然烦人，但保证了 Worker 宕机后恢复时，重放 Event History 能得到完全相同的结果。

效果如何：

• 流程编排与业务逻辑解耦，增删步骤只改 Workflow 定义不改 Activity 代码
• 长流程不因 Worker 重启丢进度，Temporal 保证 Exactly-Once 执行
• 专家确认从"异步回调"变"Signal 驱动"，前端点了确认 Workflow 自动继续
• 并行度可控，不会打爆下游服务

核心思路：PocketFlow 管单机内的小流程，Temporal 管跨服务的长期流程，Signal 插人工节点，Child Workflow 做阶段隔离。

harness

问题：什么是

harness 工程即“驾驭工程”，就是怎么构建一个运行环境使模型能稳定完成长链路任务，即模型的可控能力

问题：harness 构成

Harness五组件	手动实现方式	Hermes内建系统
指令层	手写CLAUDE.md / AGENTS.md	Skill系统（markdown skill文件，自动创建+自改进）
约束层	配置hooks / linter / CI	Tool permissions + sandbox + toolset按需启用
反馈层	人工审查 / 评估者Agent	自改进学习循环（完成任务后自动复盘优化）
记忆层	手动维护knowledge base	三层记忆（会话/持久/Skill）+ Honcho用户建模
编排层	自己搭多Agent pipeline	子Agent委派 + cron调度

问题：和openclaw 的区别

OpenClaw的Skill主要靠人工编写和调整，它的进化依赖社区和用户的主动维护。Hermes用的越久，Skill越精准，记忆越深，做事越顺手

问题：harness 怎么自进化的

harness有一个学习循环： 策划记忆->创建Skill->Skill自改进->FTS5召回->用户建模

问题：harness 的记忆设计

三层记忆： 会话记忆 持久记忆 Skill记忆