Agent 系统的三层边界:模型、工具与业务状态
当 Agent 开始修改真实数据,最重要的不是提示词,而是边界。本文讨论如何把推理、动作和状态写入拆开,让系统更容易回滚和审计。
阅读全文LLM Agent / Tool Use / Evaluation
这里记录我作为 Agent 开发工程师的实践:如何设计工具协议、拆解任务规划、构建记忆系统、做自动化评测,以及把不稳定的模型能力封装成可靠的软件接口。
$ agent run research-to-pr goal: 将需求转化为可评审的实现方案 1. parse_context() - repo map - user intent - constraints 2. plan_tools() - search code - inspect tests - verify behavior 3. execute_safely() - small patches - focused tests - explain tradeoffs result: reproducible workflow, not a one-off prompt.
选题偏工程实战,不追逐炫技。每篇文章都围绕一个具体问题:稳定性、可观测性、工具边界、评测闭环,或复杂任务的拆分方法。
我是一名 Agent 开发工程师,关注 LLM 如何真正进入软件工程、运营自动化和知识工作流。相比一次性 Prompt,我更在意可复现、可调试、可上线的系统设计。
这个博客会持续整理 Agent 工程中的实践笔记:从任务分解、上下文压缩、工具协议,到评测集建设、权限控制和人机协作体验。
这些是适合继续扩展成正式文章或项目展示的方向,可以作为你的博客长期栏目。
读取需求、定位相关模块、生成补丁、运行验证,并输出面向 Reviewer 的变更说明。重点是降低误改概率,而不是追求全自动提交。
将工单内容映射到业务流程,调用 CRM、知识库和订单工具,给出可解释的处理建议,并在人类确认后执行高风险动作。
收集真实任务轨迹,拆解为可复现用例,比较不同模型、提示词和工具实现对成功率、成本、耗时的影响。
研究什么时候该拆分角色,什么时候应该保持单 Agent。记录任务交接、共享上下文和冲突合并的设计取舍。