Agent系统构建原则 - 避免构建全能型Agent 大模型更适合处理通用任务 应专注于特定领域[3] - 明智选择应用场景 非所有任务都需要Agent 保持系统简单性优先[9] - 迭代过程中需从Agent视角思考 理解其局限性并提供必要支持[9] Agent系统演进路径 - 简单功能阶段：早期处理摘要/分类等基础任务 现已成为行业标配[9] - 工作流阶段：通过编排多模型调用形成预定义控制流 牺牲成本/延迟换取性能提升[9] - Agent阶段：模型能力强化后出现领域专用Agent 可自主决策行动路径[9] - 未来趋势：可能向通用单一Agent或多Agent协作发展 系统自主权持续扩大但伴随成本/错误率上升[9] Agent适用性评估框架 - 任务复杂度：模糊问题空间适合Agent 清晰决策路径应选工作流[11][13] - 任务价值：需验证Agent探索成本 低于$0.1/任务选工作流 高于$1可考虑Agent[11][13] - 能力可行性：关键环节需无严重瓶颈 否则应缩减任务范围[11][13] - 错误成本：高代价错误场景需设置只读模式或人工干预[11][13] - 编码是典型适用场景 因复杂度高/价值大/结果易验证[12] Agent核心架构设计 - 基础结构=模型+工具+循环 在特定环境中运作[15][21] - 优先迭代三大组件(环境/工具集/系统提示) 避免过早复杂化[16][21] - 不同领域Agent共享相似后端架构 产品层表现差异化[17] 开发者优化策略 - 模拟Agent有限上下文窗口(10k-20k token) 体验决策局限性[19][22] - 直接询问模型(如Claude)以诊断指令模糊性/工具理解障碍[23] - 优化方向包括缓存轨迹/并行化工具调用/改进用户界面[16] 未来发展方向 - 预算感知：需强化成本/延迟控制 定义时间/token预算机制[24] - 工具进化：探索Agent自设计工具能力 提升工具通用性[25] - 多Agent协作：预计年底出现生产级应用 需解决异步通信等挑战[26]