Agent 现在发展到哪一步
“Agent 已经能独立工作了吗？”没有一个简单的是或否。更准确的回答是：Agent 已经能在边界明确、 反馈及时、结果可自动检查的数字任务上持续产生价值，但能力仍然参差。任务越长、环境越开放、后果 越难撤销，就越需要 Runtime、权限、评测和人工接管。
从一次回答，发展到连续行动
Section titled “从一次回答，发展到连续行动”可以把近年的能力演进看成五层。它们不是严格年代，也不是每个系统都必须逐层实现。
| 形态 | Model 控制什么 | 典型例子 | 主要限制 |
|---|---|---|---|
| 单次生成 | 一次输入到一次输出 | 总结、分类、抽取 | 不能观察执行结果 |
| 带 Tool 的助手 | 选择一次或几次函数调用 | 搜索、查数据库、算数 | 调用链较短，边界由应用预设 |
| Agent Loop | 根据观察反复决定下一步 | 研究、客服处理、仓库修改 | 错误会在多步中累积 |
| 电脑与编码 Agent | 操作终端、IDE、网页或桌面 | 修 bug、生成报告、跨应用任务 | 环境复杂，副作用和安全风险高 |
| 持久 Agent 系统 | 跨较长时间保存状态、恢复和协作 | 长期研究、运营流程 | 恢复、评测、权限和成本更难 |
今天的主流进步不只是模型“更会推理”。Tool calling、结构化输出、多模态感知、Context 管理、代码 执行环境、执行轨迹和评测系统共同把模型变成了能行动的软件系统。
哪些任务已经比较适合 Agent
Section titled “哪些任务已经比较适合 Agent”工业实践通常优先选择三类传统自动化难处理的工作：
- 规则很多且经常出现例外，需要结合上下文判断；
- 输入主要是文档、对话、代码等非结构化数据；
- 可以通过 Tool 获取反馈，并能检查最终结果。
因此，编码 Agent、资料研究 Agent、对话式服务 Agent 和受控电脑操作成为常见方向。它们都有一个 共同点：工作发生在数字环境中，结果可以用测试、数据库状态、引用、文件 diff 或人工 review 检查。
如果问题只需要一次模型调用、检索加生成或固定 Workflow，就不必为了“更像 Agent”增加循环。 更多自由度会增加延迟、成本和失败路径。
今天的能力应该怎样衡量
Section titled “今天的能力应该怎样衡量”只问“某个 benchmark 得分多少”不够。至少要同时看：
- 任务是否接近真实环境，还是已经被整理得非常干净；
- 成功率是一次试验，还是连续多次都能成功；
- 结果是否按最终环境状态检查，而不只是让另一个模型评价回答；
- 完成任务用了多少 token、时间和费用；
- 失败是否会产生不可逆副作用；
- 人类需要在多少关键点介入。
METR 的 Task-Completion Time Horizon用“人类专家完成同类任务需要的 时间”衡量 Agent 在软件、机器学习和网络安全任务上的成功概率。它显示前沿系统能处理的任务跨度 持续增长，也明确提醒：这些任务相对干净、定义清楚，不能直接换算成整个职业的自动化程度。
较早的真实环境 benchmark 也说明“会做一部分”与“稳定接管工作”差距很大：
- TheAgentCompany让 Agent 在模拟软件公司的网页、代码和沟通环境 中完成工作，研究结论是简单任务已经可行，较难的长程任务仍明显受限；
- OSWorld用真实操作系统和桌面应用测试电脑操作，暴露了 GUI 定位、 操作知识和跨应用流程的困难。
这些数字会随模型和 Agent harness 快速变化，所以更适合用来理解问题形状，不宜把旧 baseline 当成 今天所有产品的能力上限。
为什么同一个 Model 放进不同系统，表现会差很多
Section titled “为什么同一个 Model 放进不同系统，表现会差很多”Agent 不是 Model 的别名。实际表现还取决于：
- Context 是否包含正确规则、目标和必要信息；
- Tool 名称、描述、参数和结果是否容易理解；
- Runtime 是否限制循环、处理错误并保留进度；
- 环境是否能提供清楚反馈和可验证结果；
- 是否有针对真实失败模式的 eval；
- 高风险动作是否要求独立 Policy 或人工确认。
一个强模型配上模糊 Tool、无限上下文和不可观察的副作用，可能比一个简单 Workflow 更不可靠。 反过来，明确接口、短反馈回路和可执行测试能显著提高 Agent 的有效性。
工业界目前在把“演示”变成“系统”
Section titled “工业界目前在把“演示”变成“系统””工业落地的重点正在从“模型能不能调用 Tool”转向：
- 怎样选择真正需要灵活判断的用例；
- 怎样先用单 Agent 和少量清晰 Tool 建立基线；
- 怎样让 Tool 调用受权限、timeout 和输出上限约束；
- 怎样用 trace、eval 和最终环境状态定位失败；
- 怎样控制 token、延迟和模型成本；
- 怎样在不确定或高风险节点交还给人。
这也是为什么现代 Agent 产品常同时建设 observability、sandbox、approval、eval dataset 和持久状态。 它们不是模型能力的附属包装，而是系统可靠性的主要组成部分。
BearAgent 对当前阶段的判断
Section titled “BearAgent 对当前阶段的判断”BearAgent 不把“接入更多模型和 Tool”当作第一目标。它先选择一个很小、结果可检查的本地文件任务， 再建设几条底线：
- Model 和 Tool output 都是不受信任数据；
- 外部副作用只能经过统一执行与 Policy；
- Event 保存事实，状态可以从事实确定性计算；
- 每次 Activity 受次数、token、费用和时间预算限制；
- 结果不明时不能宣称成功，也不能盲目重试。
当前 P1 已把这些底线接进一条可运行的本地文件任务：CLI 会显式选择模型协议，Agent Loop 只调用
注册过的 workspace Tool，SQLite 保存 Event，输出只原子写入 outputs/**。这证明的是一个受限场景
已经走通，不是通用 Agent、崩溃恢复、用户 Approval 或 sandbox 已经完成。
下一页继续看Agent 仍然难在哪里，以及这些问题为什么同时出现在工业系统和学术 研究中。全部来源和延伸阅读集中在参考资料。