过去两年，AI 编程产品最常见的竞争方式，是比较模型能力、上下文长度和代码生成速度。

但进入 2026 年后，竞争重点正在发生变化。

真正决定 Agent 能否进入生产环境的，不再只是“它会不会写代码”，而是另外几个问题：

• 它能否连接完整的企业知识和工具？
• 多个 Agent 能否按角色分工，而不是重复输出？
• 成本、速度和推理质量能否按任务分别控制？
• 子 Agent 跑到哪里、为什么阻塞，用户能否实时看到？
• 环境、记忆、权限和任务状态发生变化时，能否通知外部系统？
• 涉及生产资源时，是否有审批、凭证隔离和审计？

Anthropic 近期为 Claude Managed Agents 补充的一组能力，很值得从这个角度观察。表面上看，这是一次功能更新；往深一层看，它更像是在为 Agent 补齐“操作系统级”的基础能力。

一次会话支持 500 个 Skills，重要的不是数字

图 1：500 Skills 的关键不是把更多提示词塞进上下文，而是形成可检索、可授权、可版本管理的能力目录。

最吸睛的变化，是单个会话可使用的 Skills 数量从 20 提升到 500。

Skills 可以理解为注入 Agent 的专业能力包：里面可能包含业务规则、操作步骤、工具说明、代码规范或特定领域知识。

如果只是给一个通用聊天 Agent 增加几个 Skills，解决的是“回答得更专业”的问题；当一个会话能够组织数百项 Skills，并让多个 Agent 在统一环境中使用时，解决的就开始变成“一个完整业务部门如何运转”的问题。

例如，一个金融服务场景可能同时需要：

• 开户与 KYC 规则；
• 反洗钱和合规检查；
• 多语言客户沟通；
• 投诉分级与升级流程；
• 数据查询和报表生成；
• 代码规范、测试要求和部署约束。

这里真正有价值的不是把 500 份说明粗暴塞进上下文，而是建立一套可检索、可选择、可授权、可版本化的能力目录。Agent 只在需要时获得必要技能，协调者负责把合适的能力分配给合适的角色。

换句话说，Skills 正在从“提示词附件”变成 Agent 平台的能力注册中心。

按 Agent 调节思考强度，成本控制终于进入角色层

另一个关键变化，是可以为不同 Agent 设置不同的思考强度。

在真实系统里，不同任务的价值和难度差异很大：

• 分流和格式检查，更看重响应速度与成本；
• 产品答疑，需要一定推理，但不必每次都深度思考；
• 复杂故障定位，需要结合代码、日志和上下文持续分析；
• 安全、法律和生产发布审查，更看重质量和完整性。

如果整个会话只能使用同一个推理档位，要么简单问题消耗过多，要么复杂问题思考不足。把强度配置下沉到 Agent 角色后，平台才有机会真正平衡质量、延迟和预算。

示意配置可以抽象成下面这样：

# 示意代码，并非官方 SDK 原样
triage_agent = create_agent(
    name="triage",
    effort="low",
    skills=["intent-routing", "faq"]
)

review_agent = create_agent(
    name="security-reviewer",
    effort="max",
    skills=["secure-coding", "release-policy"]
)

这对多 Agent 系统尤其重要。多 Agent 不应意味着“每个角色都使用最贵配置”，而应该意味着按职责分配模型、上下文、工具和预算。

会话冷启动、子 Agent 流式输出，解决的是运行时问题

过去创建 Agent 会话时，常见做法是先建立空会话，再补发初始化事件。并发一高，初始化链路会变长，也容易产生状态不一致。

允许在创建会话时直接携带初始事件，本质上是让 Agent 从启动瞬间就知道：

• 本次目标是什么；
• 已经确认了哪些约束；
• 允许使用哪些资源；
• 验收标准是什么；
• 哪些动作必须暂停并等待审批。

这和操作系统启动进程时注入参数、环境与权限非常相似。好的 Agent 冷启动，不应该从一句“你好”开始，而应该从一个最小但完整的任务上下文开始。

与此同时，子 Agent 输出可以细化到独立流式观察，也补上了多 Agent 系统长期存在的“黑盒”问题。

以前用户可能只看到主 Agent 还在运行，却不知道某个子 Agent 是正在分析、已经跑偏，还是卡在工具调用。细粒度流式观测让协调者和用户能够更早发现阻塞、重复劳动与异常消耗。

从工程角度看，可观测性不是锦上添花，而是多 Agent 从 Demo 走向生产的前提。

图 2：细粒度观测让协调者实时发现子 Agent 的阻塞、跑偏、异常成本和重复消耗。

生命周期 Webhook，意味着 Agent 开始融入企业系统

另一组值得关注的更新，是环境和记忆生命周期事件的补齐。

当 Agent 环境暂停、恢复、创建或销毁，当记忆写入、更新或撤销时，外部系统能够收到事件，企业才可以把 Agent 接入现有的监控、告警、审计和数据平台。

这会带来几个直接变化：

1. 环境异常可以自动触发告警；
2. 任务状态可以同步到项目管理系统；
3. 记忆或知识更新可以进入企业数据治理流程；
4. Agent 使用了哪些资源，可以形成可回放记录；
5. 预算、权限和审批状态可以联动外部系统。

当这些事件形成闭环，Agent 平台就不再只是一个 API 集合，而更像一个可运维的运行平台。

Agent 平台的竞争，正在转向“OS 级深度”

把这些更新放在一起，会看到一条很清晰的演进路线：

能力层	解决的问题	工程价值
Skills 与知识层	Agent 会什么、能调用什么	形成可复用、可授权的能力目录
编排与运行时	谁来拆任务、谁来执行	支持角色分工、并行和失败处理
成本与推理配置	每个角色应投入多少资源	在质量、延迟和预算之间动态取舍
可观测性	Agent 跑到哪里、为何阻塞	支持监控、调试、接管和复盘
生命周期事件	如何接入企业现有系统	打通告警、审计、数据和运维平台
安全治理	Agent 可以访问什么	把审批、凭证和最小权限纳入执行链路

多 Agent 并不天然比单 Agent 更强。

如果没有统一的上下文、明确的职责、受控的工具、可见的状态和可验收的结果，增加 Agent 数量只会增加沟通成本、Token 消耗和失败概率。

真正的分水岭，是能否把多个 Agent 组织成一支“可管理的数字化团队”。

放到软件开发场景，团队真正缺的是什么？

以开发一个面向小团队的任务管理 SaaS 为例。需求可能包括登录、项目、任务、评论、通知和后台管理，并希望部署到 Azure。

一个只会聊天的 AI 编程助手，通常可以给出架构建议和局部代码；但真实交付还需要完成：

1. 读取现有 Git 仓库和项目文档；
2. 澄清需求范围并形成验收标准；
3. 让产品、前端、后端、评审与运维角色协作；
4. 执行代码修改、构建和测试；
5. 使用云资源但不暴露长期密钥；
6. 在生产部署、数据库修改等高危节点等待人工审批；
7. 汇总代码、测试结果、部署说明和审计记录；
8. 上线后继续修复、迭代和升级。

这也是为什么软件开发 Agent 的核心价值，正在从“生成一段代码”转向“持续推进一个可验收的交付过程”。

Heicode 的思路：把 Agent、资源和治理放进一条工作流

图 3：Heicode 将目标、资源连接、Agent 协作、编码测试、人工审批、部署与审计组织成可验收的交付闭环。

Heicode 正是沿着这条路径设计的一款智能开发工具。

它的目标不是再做一个模型聊天窗口，而是面向软件生命周期，把自然语言目标、Agent 分工、项目资源、代码执行、测试验证、部署交付和安全治理组织到同一条工作流中。

用户在客户端描述目标并持续沟通；浏览器里的 Heicode Manager 负责资源准备、Agent 启动、状态、模型用量、日志和审计。两者分工明确：客户端更像协作入口，Manager 更像控制面。

一个典型流程可以概括为：

描述产品目标
→ 连接 Git、项目文档、团队 Skills/SK 与云资源
→ 查看系统整理的角色、资源、预算和风险摘要
→ 启动 Agent 执行开发、测试与修复
→ 在高危节点由用户审批
→ 验收代码、测试、文档和部署结果
→ 继续追加需求并复用已有项目上下文

这里有几个与“Agent OS”趋势高度一致的设计点。

1. Skills 不只是数量，更需要上下文和权限

Heicode 可以连接团队的 SK 技能库、项目文档和外部工具。重点不是把所有知识一次性灌给 Agent，而是围绕当前任务生成资源摘要，只允许角色使用必要的上下文和能力。

2. Agent 团队按任务组建

简单任务可以使用 1～2 个 Agent；功能开发可以组合 Product、Frontend、Backend 和 Reviewer；生产发布则需要 Ops、Reviewer 以及更严格的审批。

敏捷和瀑布模板帮助团队快速选择协作方式，避免为了“多 Agent”而盲目增加角色。

3. 长期密钥不进入 Agent

Git、云和数据库的长期凭证进入密钥保管器，服务端只保存引用。任务执行时再按权限派生短期、最小权限凭证，到期或任务结束后失效。

这意味着 Agent 可以使用真实项目资源，但不需要长期持有“万能钥匙”。

4. 高危操作由人确认

生产部署、数据库写入、云资源创建或删除、生产密钥访问和大额预算消耗等操作，需要在客户端审批并留下记录。

用户可以放手让 Agent 工作，但不必放弃控制权。

5. “完成”必须有可验收证据

Heicode 区分流程结束、产生修改、验证通过和问题解决。最终交付不只是一个“已完成”状态，还应包含代码差异、测试结果、失败原因、部署说明与审计摘要。

一个需要明确的能力边界

Agent 产品最容易出现的问题，是把目标形态写成已经全面上线的能力。按照 Heicode 当前产品文档，已经过生产验证的是模板 Agent 主链路：在 Manager 中选择模板和资源、部署常驻 Agent，并在客户端直接使用；模型调用、余额和用量也进入统一管理。

Agent Swarm 多 Agent 蜂群运行时，以及从需求到长期维护的更完整自动闭环，仍属于持续建设方向。保留这个边界，能让开发者更清楚地判断今天可以解决什么、未来又将向哪里演进。

写在最后

从 500 个 Skills、按角色调节思考强度，到子 Agent 流式观测和生命周期 Webhook，行业释放出的信号已经很明确：下一阶段的平台不会只比模型数量和上下文长度，而会比谁能把知识、角色、资源、权限、成本、事件和交付组织成稳定系统。

对开发者而言，更值得关注的也不只是“AI 能写多少代码”，而是它能否进入真实仓库、遵守团队规范、在安全边界内调用资源，并交付可检查、可继续迭代的结果。

如果你正在尝试用 AI 完成一个真实软件项目，可以从一个边界清晰、可验证的小任务开始：连接项目、选择团队、确认权限，让 Agent 先把下一步真正做出来。

Heicode：https://code.heicode.cc/

---

参考阅读：Claude Agent 突然大更新！狂塞500个技能，网友直呼疯狂

说明：本文结合公开更新信息与 Heicode 2026-07-23 产品文档撰写。产品能力可能继续调整，正式发布前请以最新版本状态为准。