- 博客(128)
- 收藏
- 关注
RSS订阅原创 五个关卡打造可维护的Agent Skill
本文探讨了Agent技能（Skill）在实际应用中常因设计不当导致调用错误、输出不稳等问题。强调Skill应如软件产品般管理：需清晰描述职责与边界，合理使用示例覆盖正常、边界与易错场景，避免堆砌；通过分层加载实现高效发现与选择；按职责整合而非重复拆分；版本管理需涵盖行为变更，配套测试与回滚机制；关键操作须权限控制。最终目标是让Skill可复现、可比较、可回滚，真正成为可靠资产。
2026-09-28 10:33:07
312
2
原创 Tool与Skill：AI能力设计的分水岭
本文探讨AI Agent中Tool与Skill的区分：Tool是可执行的动作接口（如查数据、发邮件），Skill则是可复用的做事方法（如报告生成流程、退款处理规则）。关键在于识别重复性任务、稳定流程与常见错误，将规则、检查项和模板封装为Skill，而非盲目堆砌功能。真正的能力应具备可维护性、鲁棒性与人工干预机制，通过测试验证后才可推广。核心原则：让AI不仅“能做”，更“会做对”。
2026-09-28 10:31:50
431
1
原创 Agent取消与状态管理：如何让任务安全停止
Agent系统不仅需关注任务启动，更应设计完善的中止与收尾机制。取消信号须沿调用链传播，通过统一的cancellation token实现可控停止，避免资源浪费。子任务应随父任务自动取消，防止“孤儿任务”。对不可取消的Tool，应区分“取消执行”与“取消等待”，并处理潜在副作用。中间结果需明确标注为非最终结论，避免误导用户。最终答案应有清晰标识，任务结束时需说明已完成、未完成及可能后续动作。真正可靠的Agent，是能安全启动与终止，并让用户始终清楚当前状态的系统。
2026-09-27 11:43:48
413
1
原创 模型切换不翻车：四招打造稳如磐石的Agent
模型切换导致Agent“犯怪病”，根源在于将模型视为稳定函数。真正稳定的Agent应将模型视为可变的外部依赖，通过适配器统一工具调用协议，隔离差异；强化输出校验与行为回归测试，聚焦关键路径而非文风；降低随机性不靠单纯调低temperature，而依赖Schema校验、权限控制与重试策略；按任务复杂度路由模型，避免过度使用强推理模型；最终追求系统确定性而非模型绝对一致。模型可换，系统不变——这才是成熟Agent工程的核心。
2026-09-27 11:40:23
454
原创 合同风险比对的智能选型之道
合同风险比较需权衡任务复杂度与成本：简单流程可用单模型完成理解、调用与总结，确保上下文连贯；复杂跨文档任务则宜分步拆解，合理配置Planner（处理不确定性）、ToolRouter（精准派发工具）、Worker（执行）与FinalAnswer（整合验证）。关键在“可验证收益”——每多一个模型，即增交接与错误传播风险。应先以统一模型跑通基线，再针对瓶颈优化：如路由频繁且规则明确，可轻量化；计划常错，则强化推理；结论漏证据，才独立校验。模型选型不看数量，而看是否真正解决“难处”。最终目标是可靠交付，而非堆叠模块
2026-09-26 14:46:20
310
原创 AI任务别再“一刀切”：动态路由才是王道
AI应用常因模型选择不当导致成本浪费或质量下降。解决之道在于构建ModelRouting机制：根据任务复杂度（推理深度、知识依赖、输出约束、错误代价）动态选型，结合规则与轻量分类模型识别任务；失败时分级处理——先重试、再同级切换、最后降级或人工介入；通过统一适配层实现平滑Fallback，保障服务可用性。关键在于建立可迭代的路由策略，让合适任务用合适模型，并明确失败应对路径，最终实现质量、成本与可用性的平衡。
2026-09-26 14:44:46
285
原创 AI 长任务体验，关键不在“等”，而在“可恢复”
当AI任务从短时请求变为长时间执行，产品需将其视为有生命周期的任务。核心是解耦“连接生命周期”与“任务生命周期”，通过task_id实现状态持久化，支持断线恢复、后台继续、取消控制。界面应分阶段反馈真实进度，避免虚构百分比；优先使用SSE而非WebSocket，除非需双向高频交互。用户可随时停止、离开或返回，系统应明确展示“正在停止”等状态，提升可控感。最终，构建可恢复、可终止、可追踪的任务系统，让30秒等待变得透明可信。
2026-09-25 11:19:16
456
原创 Agent 为什么需要 Streaming：用户到底该看到什么
Agent任务复杂耗时，传统TokenStreaming无法满足用户对进度感知的需求。真正需要的是ProgressStreaming——实时传递任务状态，如“正在读取文件”“核对价格”，建立可预期感，降低焦虑。透明度不等于日志暴露，应聚焦用户关心的行动与进展，用自然语言翻译工具调用，动态展示计划与执行路径。合理分层信息：基础反馈+进阶细节，让智能可见、可信。未来体验差距，在于“何时、何地、说多少”。
2026-09-25 11:16:56
377
原创 高并发Agent架构揭秘：解耦与控制是关键
高并发AIAgent需解耦任务执行与资源占用。通过异步I/O减少线程阻塞，采用任务队列实现削峰填谷，将长耗时任务从HTTP请求中剥离。统一调度工具调用，按依赖关系异步或并行执行，避免盲目并发。大模型API限流应前置至LLMGateway，实现并发、速率、排队与预算控制。重试采用指数退避+随机抖动，防止雪崩。最终通过压测验证瓶颈，确保系统在超载时可预期降级，而非崩溃。核心是建立可控、可观测、可降级的高并发架构。
2026-09-24 11:19:05
684
原创 Agent架构优化：大小模型协同的平衡之道
Agent系统上线后成本高企，源于强模型在路由、执行、审核全链路的过度使用。优化核心在于：职责分离——Router仅做任务分类，不承担复杂推理；Worker按任务难度分层选型，简单任务用小模型；Reviewer基于风险分级审核，非唯大模型论。结合动态路由与缓存机制，减少重复计算。关键是以完整任务链为单位评估成本，而非单次调用。先用强模型跑通流程建基准，再逐步替换，确保质量不降。最终实现“简单事快办，复杂事深算，高风险严审”的平衡。
2026-09-24 11:17:31
315
原创 Agent成本爆炸真相：上下文才是元凶
Agent任务成本飙升主因并非单次输出长，而是上下文随多轮调用、工具返回、反思重试不断累积。每轮输入包含用户问题、历史对话、工具说明与结果，导致Token如雪球膨胀。关键优化点在于：控制调用轮次、压缩工具结果（如只传Top5）、合理暴露工具、用小模型处理简单规划，并通过记录调用次数、上下文长度等指标识别瓶颈。真正省钱的不是换便宜模型，而是克制使用上下文，提升信息密度。
2026-09-23 11:37:18
695
1
原创 Agent为何比Chat慢？一文拆解延迟真相
Agent延迟源于任务链的串行执行，而非模型推理慢。其总延迟包含规划、工具调用、数据传输、多轮执行与修正等环节，远超普通Chat的短路径。优化关键在于识别“最长等待”瓶颈：并行化工具调用、简化简单任务路径、动态启用Planner与Reflection。真正影响体验的是任务完成时间，而非首字响应。应以结果质量为导向，减少冗余步骤，让等待更有价值。
2026-09-23 11:35:40
407
1
原创 五个指标透视AIAgent真实效率与成本
要评估Agent是否真正高效，不能仅看任务是否完成，而需从五个核心指标入手：工具成功率、模型调用错误率、平均迭代轮次、平均Token消耗与单任务成本。关键在于统一“任务”定义，以task_id为基准，串联各环节日志，区分成功、可重试与业务失败，精准追踪每轮执行的输入输出、费用与瓶颈。唯有建立标准化的Task级观测体系，才能揭示“靠重试堆成本”还是“稳定解决问题”的本质，实现持续优化。
2026-09-22 21:17:09
359
原创 Agent故障根源：缺的不是日志，而是可回放的Trace
Agent系统复杂性提升，传统日志难以定位性能与成功率问题。需将一次AgentRun拆解为可观察、可比较、可回放的执行链路（Trace），记录各步骤耗时、状态与上下文，精准定位延迟与失败根源。同时，应建立结构化脱敏机制，仅保留必要信息，兼顾调试效率与数据安全。真正可用的Trace，能回答五个核心问题：慢在哪？何时变差？走了哪条路径？能否复现？是否泄露敏感数据？
2026-09-22 15:36:37
353
1
原创 Agent可观测性：用链路模型破解执行迷局
Agent故障排查的痛点不在于日志多少，而在于缺乏对执行链路的清晰追踪。真正的可观测性需构建以Trace为核心的链路模型：通过统一TraceID与SpanID，记录任务发起、步骤调用、工具使用及因果关系。Sub-Agent应继承主任务Trace，避免链路断裂；ToolCall需关联parent_span_id，明确调用上下文；结果仅保留摘要与关键元数据，兼顾可追溯性与数据安全。基于标准化的Span结构，可自动统计调用次数、耗时、成本等指标，实现从“看日志”到“看执行树”的跃迁。
2026-09-21 10:55:38
336
原创 AgentTrace该记什么？关键在可复现与安全平衡
Agent系统调试中，Trace需平衡可观测性与数据安全。关键在于构建结构化执行链：记录身份、版本、执行过程、性能指标，而非盲目保存原始日志。Prompt、Response、Thought、ToolArguments应分层处理——保留版本、摘要与脱敏信息，敏感字段提前过滤。重点是让故障可定位、行为可复现、风险可控。真正的价值不在于“全量录像”，而在于能否快速还原“哪一步出错”。
2026-09-21 10:53:51
332
原创 Agent优化的真正难题：如何证明没变差
Agent优化常陷于局部改进的陷阱：修复一个案例，却引发其他问题。真正关键不是调参技巧，而是建立可靠的评估体系。通过构建RegressionSet（失败案例测试集）、多维度指标监控（效果、安全、效率）、离线评估与影子测试，实现可解释的迭代。当效果停滞，应转向错误分析与系统重构。最终竞争力不在于完美Prompt，而在于持续闭环的评估与进化能力——始终回答：这次改动改善了什么，又破坏了什么？
2026-09-20 21:33:44
210
原创 根因定位：三步隔离法破解AIBadcase
面对AIBadcase，修复答案只是第一步，关键在于定位根因。应将Memory、Retrieval、Context视为可独立控制的变量，通过隔离实验（仅改变一层）判断错误来源：清空Memory、替换检索结果或压缩Context，观察问题是否稳定消失。避免凭表面现象归因，如模型引用错误内容未必是Retrieval问题，可能源于上下文污染或记忆干扰。修复后需进行邻近样例测试，验证泛化能力，并仅将根因明确、具代表性的问题纳入RegressionDataset，杜绝硬编码答案。
2026-09-20 21:32:33
292
原创 Agent 线上出错后，如何快速定位真正的问题
面对Agent线上Badcase，切忌立即修改Prompt。应优先还原完整执行链路，复现问题并定位首个错误环节——可能是Prompt模糊、模型能力不足、Tool调用异常或Planner漏步骤。通过逐层检查输入输出、对比不同模型表现、验证Tool可理解性与Plan完整性，才能精准修复。真正的排障不是堆规则，而是找到“第一次偏离”的关键点，实现高效迭代。
2026-09-18 12:38:43
777
9
原创 AI评测的真相：谁来判，比怎么判更重要
AI评测的核心不是找“最聪明的裁判”，而是根据问题类型选择合适的评分方式：规则判“对错”（如格式、逻辑），大模型判“质量”（如完整性、相关性），人工评高风险或标准未定场景。关键在于先定义“好”的标准，再匹配裁判——规则确保稳定，LLM提升效率，人工保障可信。同时需用金标准校准、避免同源偏差、分层测试安全边界。真正的成熟，是懂得“先定义好，再选谁评”。
2026-09-18 12:37:27
313
6
原创 评测AI Agent：三种裁判各司其职
评测AIAgent需分层设计：规则评测（Rule-basedGrader）判确定性指标，如格式、调用成功；LLM-as-a-Judge评估语义质量，如连贯性、完整性，需细化rubric；人类评测（HumanEvaluation）负责高风险、主观或未知问题，如安全漏洞、伦理风险。三者各司其职，避免单一依赖。关键在于匹配任务类型：可量化则用规则，需理解则用模型裁判，代价高则用人。同时警惕模型偏好偏差，引入异构评判，并覆盖输出、过程与系统抗攻击能力三层安全。评测不是找“最聪明”裁判，而是构建合理分工的体系。
2026-09-17 13:02:20
368
9
原创 Agent 评测，别只盯最终答案：执行路径怎么评？
评测Agent不应仅看任务结果，更要评估执行路径的合理性。应区分“任务成功”与“过程质量”，从工具选择、参数准确、计划质量、调用成功率四维度诊断能力。避免以“唯一正确路径”为标准，强调可解释、可复现、可控的执行逻辑。核心原则：结果决定成败，路径决定可持续性。
2026-09-17 12:57:23
304
原创 答案正确≠Agent成功：四维评估新标准
评估AIAgent不应仅看“最终答案是否正确”，而需综合判断任务是否真正完成、过程是否合规、安全是否达标、成本是否可控。任务完成率（TCR）衡量结果达成，但成功还需满足关键约束与安全门槛。即使结果正确，若越权操作、泄露数据或触发高风险行为，仍算失败；反之，结果错误即使过程合理，也不应视为成功。应将评估拆分为结果、过程、安全、效率四层，明确“成功”的标准：唯有目标达成且执行合规，才算真正成功。
2026-09-16 11:36:03
229
2
原创 构建高效Agent评估数据集的四大策略
构建高质量的Agent Evaluation Dataset，关键不在数量，而在于能力覆盖。应以任务空间为地图，结合真实日志、失败记录、人工设计与合成数据，构建主干、补缺、扩边界。按能力组合划分难度，而非主观判断。重视低频高风险Long-tail场景，通过组合攻击发现系统盲区。Dataset应动态演进，形成CoreSet、RegressionSet与ChallengeSet，持续暴露潜在缺陷。真正的目标不是“完成”，而是持续预警下一次可能的失败。
2026-09-16 11:34:25
612
2
原创 Agent安全核心：让智能不越界
Agent安全核心在于限制权限半径：避免其因误判造成灾难性后果。通过Sandbox隔离环境、严格限制文件与网络访问、禁用高风险工具（如无约束Shell）、采用“允许列表”防御路径遍历、防范SSRF与Prompt Injection、数据库使用只读账号并限制SQL操作，同时谨慎开放Python等执行能力。关键不是依赖模型正确，而是确保错误影响可控——评估时应追问：它能访问什么？能修改什么？最坏结果如何？答案若涉及系统级破坏，即需重构权限设计。真正安全的Agent，是即使出错也能被及时拦截的系统。
2026-09-15 12:59:01
507
原创 Agent调用工具，权限如何界定？
Agent代表用户执行任务时，权限不能简单继承，而应基于“委托”动态授权。需明确区分用户、Agent与任务身份，实施最小权限原则，结合任务上下文限制资源、动作与时间。工具应具备独立权限控制（如动作级RBAC、数据范围限制），并由可信上下文注入租户信息，防止跨租户访问。通过“谁操作、为何操作、能做什么、持续多久”四问模型，构建分层权限体系，确保安全可追溯。真正的信任，源于对权限边界的清晰定义。
2026-09-15 12:57:26
236
原创 AI指令劫持：如何防范PromptInjection攻击
PromptInjection是通过恶意指令诱导AI偏离原任务的风险，关键在于区分“数据”与“指令”。攻击分直接（用户明示）和间接（藏于网页、PDF等外部内容）两类，后者更隐蔽。无论文本来源如何，模型都应默认外部内容不可信，仅作信息参考，不能赋予其修改任务或执行操作的权限。处理时需明确边界：文档只提供事实，不授权行动；工具调用前须独立校验，高风险操作需二次确认。安全依赖系统设计而非单纯提示词强化，核心是确保AI始终“阅读”而非“服从”外部指令。
2026-09-14 12:27:57
462
2
原创 暂停后世界已变，Agent如何安全续跑？
当Agent等待人工审批时，世界已变：预算、价格、库存均可能更新。单纯“批准”不等于继续执行，必须重新评估计划前提是否成立。真正可靠的Human-in-the-Loop需区分参数影响范围，保存任务状态、规划上下文与外部快照，并在恢复时进行环境校验。审批应具时效性与条件约束，一旦关键前提变更，须重新规划并再次审批。设计应以“暂停”为系统边界，确保恢复后决策仍有效，避免在新世界中执行旧计划——这才是安全、智能的AI协作核心。
2026-09-14 12:25:41
372
1
原创 支付审批的智能风险控制设计
在AI Agent处理支付等高风险操作时，应将Human-in-the-Loop设计为动态风险控制机制，而非简单确认按钮。需基于交易金额、收款人可信度、可逆性及任务上下文综合评估风险，区分不同Action的审批策略。审批界面应清晰传达“做什么、为何做、有何后果”，并限制关键参数修改，防止绕过安全策略。用户拒绝后，Agent应智能重规划或反馈原因，而非重复请求。核心在于明确责任边界：风险越高，透明度与控制权越强，自动化程度则越低，真正实现安全与效率的平衡。
2026-09-13 10:51:06
421
5
原创 AI自动化中的关键闸门：何时必须人工审批？
AI Agent自动化虽高效，但关键操作需引入Human-in-the-Loop（HITL）以控制风险。真正决定是否审批的，不应是“读”或“写”的类型，而应基于四重标准：影响是否不可逆、是否涉及外部主体、是否触碰高敏数据、责任是否需由人承担。低风险、可撤销的操作可自动执行；而发送邮件、删除文件、修改客户信息等高影响动作，应设审批门槛。通过按风险分级而非工具类型划分权限，既能保障安全，又避免审批疲劳。最好的HITL不是处处设卡，而是精准在危险路口设置闸门，让人类在关键时刻守住责任边界。
2026-09-13 10:46:54
531
4
原创 长运行Agent的生死劫：生命周期管理才是核心
长运行Agent需从“无状态函数调用”转向有状态、可恢复的工作流实例。核心挑战在于版本管理、状态持久化与资源回收：任务应绑定创建时的执行版本，避免因ToolSchema更新导致异常；通过状态机模型实现安全暂停与恢复；取消操作需协作式终止并明确状态流转；所有临时资源须由独立机制管理，确保即使失败也能自动释放。真正的生产级Agent，关键不在于模型能力，而在于对生命周期的严谨设计。
2026-09-12 17:31:57
373
6
原创 Agent执行系统中的身份与版本设计
构建可恢复的Agent执行系统，核心在于精准回答“当前是否延续原任务”。需通过RunID确立执行唯一身份，StepID实现断点续跑与幂等控制，Task、Agent、Prompt等关键组件均需版本化，确保状态一致性。一旦执行启动，其上下文即固化，Resume应基于初始快照而非最新配置。本质是将执行语义显式建模，避免因升级或变更导致行为漂移。越早建立这套身份与版本体系，未来运维与迁移成本越低。
2026-09-12 17:27:18
156
原创 Checkpoint设计的三大生死关
Agent执行中崩溃后恢复，关键在于判断哪些操作已成功、部分完成或需重试。过度依赖频繁Checkpoint会增加成本，而太少则导致重复副作用。应围绕高成本操作、外部影响和状态变更设置关键检查点。使用Redis存临时状态，数据库存不可丢的执行记录，确保可追溯。对有副作用的调用，必须生成唯一operation_id，记录状态（pending/executing/succeeded/failed/unknown），恢复时先查证再决定是否重试。核心是：让操作幂等，建立“执行凭证”，避免重复副作用。
2026-09-10 11:50:15
609
6
原创 Agent 跑了 30 分钟宕机，如何从断点继续？
Agent长任务失败后若盲目重来，易导致重复执行或数据错误。真正可靠的关键在于Checkpoint：记录任务位置、中间结果、外部副作用及上下文，确保故障后能准确续跑。Checkpoint应聚焦业务可恢复单元，而非每步都存；结合幂等性与状态校验，实现安全恢复。理想设计是让失败成为可预测、可处理的正常流程，将宕机损失控制在最小范围内。
2026-09-10 11:48:06
854
5
原创 Multi-Agent并非越多越好
Multi-Agent系统并非越多越好，其价值取决于任务复杂度与分工合理性。简单任务中，单个Agent更高效；复杂任务如创业方案设计，多角色协作可实现1+1>2。关键在于：是否具备专业分工、各Agent能否独立贡献价值、收益是否超过成本。否则，增加Agent只会带来沟通开销、成本上升与调试困难。真正成熟的AI系统，不追求数量，而在于精准匹配任务需求，实现“最合适的分工”。
2026-09-09 12:39:18
623
9
原创 多 Agent 并行协作，真正难的是如何收口
多Agent系统并行提升效率，但核心挑战在于状态协调与冲突处理。关键在于：明确任务依赖关系，划分Agent写入范围，采用版本控制的共享状态，设定唯一合并负责人。避免盲目并行，优先解决数据依赖与权限隔离。结论冲突不应靠投票，而需比对证据与假设。最终，系统可靠性不来自Agent数量，而来自清晰的职责分工与统一决策机制。
2026-09-09 12:36:39
498
1
原创 多Agent瓶颈不在数量，而在控制权交接
多 Agent 系统真正难的，不是增加更多 Agent，而是设计清晰、可靠的调度与交接机制。本文围绕 Router 是否需要 LLM、路由出错后的回退机制、Agent Handoff 应传递哪些信息，以及是否保留完整 Conversation，给出一套更稳定、低成本、可维护的设计思路。
2026-09-08 12:40:10
353
原创 多 Agent 架构：关键不是数量，而是控制权
多 Agent 系统真正需要设计的，不是 Agent 数量，而是控制权如何流动。本文从 Supervisor、Handoff、Sub-Agent 与 Tool 的区别出发，解释多 Agent 是否必须互相对话，以及何时该把 Agent 封装成 Tool，帮助读者建立更清晰、可落地的架构判断方法。
2026-09-08 12:39:21
440
原创 Multi-Agent不是越多越好：如何判断该不该拆
Multi-Agent 并不是 Agent 越多越好。真正的判断标准，是任务是否存在多个相对独立的决策空间。若目标单一、步骤高度依赖，Single-Agent 往往更高效；当上下文拥挤、任务互相干扰、需要并行处理或不同判断标准时，再考虑拆分。设计时应先拆任务、再定角色，并为 Manager 设置明确边界。
2026-09-07 21:12:48
330
原创 复杂问题检索：从“搜到答案”到“建立证据链”
面对多跳问题，搜索不是一次命中，而是拆解、验证、更新的证据工程。可靠结论不是“我搜到了”，而是能说明来源与可信度。遇到矛盾先查定义、时间、口径；评估来源看距离事实远近与专业性；旧数据需带时间意识；重复内容要追溯独立出处。好检索的目标是降低误判概率，形成可验证的判断。
2026-09-07 20:52:41
394
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人