Custom Agent 是什么：把通用模型变成专业编程 Agent

一个通用 AI 可以解释代码、写函数、运行测试，但不同任务需要的上下文和权限并不一样。前端 Agent 需要关注组件、浏览器和视觉检查；安全 Agent 需要关注依赖、权限和漏洞；测试 Agent 需要关注边界、数据和回归。Custom Agent 的思路，就是把这些差异固定成可复用的专业工作流。

Custom Agent 和普通 Prompt 有什么区别

普通 Prompt 只影响当前一次对话，下一次还要重复描述规则。Custom Agent 则可以预先定义角色、任务目标、工具范围、项目上下文和输出格式。它不是换了一个“人格”，而是把特定任务需要的约束保存下来，让每次执行都从相对稳定的起点开始。

例如，一个“依赖审计 Agent”可以默认只读 package.json、锁文件和安全报告，输出包来源、版本、许可证和漏洞清单，不允许直接安装依赖。一个“前端验收 Agent”可以默认启动开发服务器、使用浏览器操作页面，并报告键盘路径、网络错误和截图差异。

听起来反直觉：Agent 越专业，能做的事情反而应该越少。一个只负责分析数据库迁移的 Agent，不需要访问用户目录；一个只负责写文档的 Agent，不应该修改生产配置；一个只负责运行只读检查的 Agent，不应该拥有提交或发布权限。

限制工具和上下文，可以减少误操作，也让结果更容易评价。专业化不是让 Agent 说话更像专家，而是让它在一个明确的任务边界内使用合适的方法。

先定义触发场景，而不是先写一段角色介绍。然后列出它必须读取的文件、允许使用的工具、禁止执行的动作、完成标准和输出结构。最后准备几组真实任务，检查它是否会漏掉风险、提出无关修改或越权操作。

一个好的配置还要写清楚不确定时怎么办：是停止并询问，还是给出候选方案？遇到测试失败，是重试、回滚，还是提交诊断报告？这些行为边界比“你是一名资深工程师”更重要。

把任务拆成前端、后端、测试和安全 Agent，可以并行处理，但也会增加交接成本。若每个 Agent 都生成自己的假设，最后可能出现接口不一致、重复代码和责任不清。专业化 Agent 之间需要共享契约、明确输入输出，并保留一位负责整体结果的人。

不必一开始就搭建复杂的 Agent 平台。可以先选择一个反复出现、边界清楚的任务，例如“检查 PR 是否缺少测试”或“分析依赖升级风险”，把团队已有的清单和命令写进配置，再观察它是否真正减少重复劳动。

Custom Agent 的核心不是增加更多 AI，而是把团队经验变成可重复、可审查的工作流。经验被固定下来，未来每次任务就少一点临场猜测，多一点稳定边界。