Zaid（Mercury Agent 创始人）提出了一个 Agent 产品设计的核心原则：如果你的 Agent 需要为每件基本事都装技能/插件/MCP，那核心 Agent 还没准备好。
核心观点：Batteries Included
技能有用。扩展有用。自定义工作流有用。
但如果一个 Agent 需要单独加装才能读文件、检查 git 状态、运行命令、管理记忆、调度任务、获取 URL、请求审批——那核心 Agent 还没准备好。
Mercury Agent 的设计原则：自带电池（batteries included）。不是营销话术，是产品原则。
开箱即用包含：文件系统操作、shell 命令、git 操作、网页获取、调度、技能、系统预算检查、消息、子 Agent 委托。工具列表包括 read_file、write_file、edit_file、run_command、git_status、git_diff、git_add、git_commit、git_push、fetch_url、schedule_task、budget_status、delegate_task。
关键问题：扩展之前能做什么？
普通应用等用户点击按钮。Agent 推理任务、决定用哪些工具、在环境中行动。
所以问题不只是"我能扩展这个 Agent 吗？"，更好的问题是："在我开始组装额外零件之前，这个 Agent 能安全地做什么？"
Mercury 的答案：足够有用，不至于鲁莽。
权限优先
Mercury 被描述为 permission-hardened：
- 文件夹级读/写范围控制
- 待审批流程
- shell 黑名单
- 会话级权限模式（Ask Me / Allow All）
- 行动前询问
Agent 应该有能力。但能力没有边界会变成焦虑。你不应该每次 Agent 想运行命令时都感到害怕，不应该怀疑它是否未经告知就改了文件，不应该因为系统过早给了太多自由而需要检查每一步。
好的 Agent 通过可见、可控的行动赢得信任。
控制层不是装饰
Mercury 提供状态追踪：/status、/progress、/tools、/skills、/memory、/tasks、/budget，以及紧急控制：/halt、/stop、/reset。
这不是装饰，是控制层。如果 Agent 要运行长时间任务、在后台工作、使用工具、在代码库附近操作，追踪不是可选的，是基本安全。
编码工作流的原生支持
Mercury 直接支持编码工作流：
- /code plan —— 分析和选项，不编码
- /code execute —— 逐步实现
- /code agent <task> —— 委托编码工作给后台子 Agent
- 工作区命令 —— 打开目录、刷新 git 状态、暂存文件、提交更改、撤销文件编辑
三代编码 AI 的演进
第一代：自动补全 第二代：聊天 第三代：不是"更自主的编码"，而是可控委托
你不仅会要求 AI 写代码，还会要求 Agent 调查 bug、审查 diff、检查文件、总结仓库状态、运行测试、比较选项、准备计划、在隔离的子任务上并行工作。
为此，Agent 需要内置判断力和内置工具。不是一个等你手动安装每个能力的空白壳。
技能的位置
Mercury 仍然支持技能。技能在需要专业化时很棒——编码可重复工作流、团队约定、工具特定流程、领域特定行为。
但技能应该扩展 Agent，不应该补偿一个空核心。
核心 Agent 应该已经理解如何操作：如何读取、如何检查、如何询问、如何追踪、如何记忆、如何停止、如何在限制内操作。
记忆也需要边界
Mercury 的 Second Brain 是持久结构化记忆，使用 SQLite 和 FTS5 全文搜索，支持记忆类型、自动提取、冲突解决和合并。
Agent 不应该永远是无状态工作者。如果你一直在重复偏好、项目上下文、习惯、目标、约束，系统在浪费你的时间。Agent 应该记住重要的东西。
但记忆也需要边界——Mercury 的记忆是本地的、可通过 /memory 检查的。