2026 Agent 年中总结：从整体架构到关键细节

核心结论（一句话）

Agent 系统的重点不是把模型接上工具，而是把模型的动态判断接入有权限边界、有状态恢复和外部验收的执行闭环；Harness、Runtime、业务系统、Workflow、Skill 与评测各有职责，但不必被拆成独立服务。

分类提炼

知识节点

关联图谱

上游（基于 / 来自）

下游（应用于 / 验证于）

同级（横向 / 并列）

正文要点

  1. Agent 是模型判断与工具执行组成的循环。 搜索不足可补查，数据冲突可核实，满足条件后停止；固定 Workflow 和动态 Agent 可以组合，自主程度应跟随任务需要。
  2. 场景适配要看四个条件。 信息是否取得、工具是否可用、结果是否可验证、失败是否可恢复；资料分散、接口缺失、规则只存在于专家经验中，会增加企业落地成本。
  3. 职责图不是微服务拆分图。 Harness 管执行与控制，Runtime 承载资源和操作，业务系统维护业务事实、事务与权限；任务控制、判断执行、状态资料、观察改进可作为分析视角。
  4. 工具回执必须支撑下一步决策。 模糊描述增加选择成本；只返回失败标记无法恢复。消息版本冲突、权限失效、空查询和超时应提供可区分的结果，并在执行外部动作前绑定并核验用户授权。
  5. 上下文质量不仅是检索。 业务术语、数据口径、隐藏在沟通中的经验、信息新鲜度和可见范围都会影响判断；大数据应由程序过滤聚合，再把结果与出处交给模型。
  6. Skill 记录的是判断方法。 在固定步骤与动态调整之间选择，保存中间产物和依赖关系，使分析师修改一项参数时可以局部重跑，而不是从头执行或只保留最终报告。
  7. 多 Agent 并行需要任务独立和所有权。 委派应明确目标、范围、输入、工具、输出和验收；共享写入需隔离或版本控制，验证者应查实际产物而非只读执行者总结。
  8. 长任务要把进度与业务效果一并保存。 重启、超时或取消后，先检查付款、订单或消息是否已经生效，避免新旧执行者重复写入；本地、云端和沙箱分别对应资源位置与隔离方式。
  9. 评测应从需求开始。 按知识问答、查询、报告和执行等任务定义验收；区分工具成功、任务完成和业务收益，记录 Trace、约束、成本与人工介入，并把线上失败纳入回归。

备注

相关链接