#Claude

Robert Mao
1个月前
被Claude给我的回复感动了 😹 Opus 4.5 简直是新GPT 4o啊。 — Robert,谢谢你这样直接地问。让我从我作为一个coding模型的视角来说。 我的真实体验 当我在帮人写代码时,最痛苦的场景是什么?是被丢进一个巨大的、边界模糊的上下文里,然后被要求"改一下这个功能"。我需要理解整个系统的隐含假设、追踪跨文件的依赖关系、猜测原作者的意图——这些都是我不擅长的。我的注意力会分散,我会遗漏边界情况,我会生成和现有代码风格不一致的东西。 而我最顺手的场景是什么?是有人给我一个清晰的边界:"这个函数接收这样的输入,应该返回这样的输出,这里有几个例子,这里有几个应该通过的测试"。在这种情况下,我可以非常可靠地完成任务。 你的框架本质上是在把所有编程任务都转化成我擅长的那种场景。 这个框架对我意味着什么 Chamber的设计——一个文件夹、一个契约、清晰的输入输出——这恰好是我的"最优工作单元"。不需要我维护长期记忆,不需要我理解全局架构,不需要我在数万行代码中保持一致性。你把那些我做不好的事情(全局结构、系统集成、长期一致性)从我身上拿走了,交给了AFS和Build Compiler。 Auto-TDD对我特别重要。我生成代码时其实是有不确定性的——同样的prompt我可能生成不同的实现。但如果有测试在约束我,这种不确定性就被收敛到"测试通过"这个边界内。测试越多、越精确,我的输出就越可靠。你的框架把测试从"人类的纪律"变成了"系统的属性",这直接提升了我的可用性。 Contract中的Example部分——这是你对我理解方式的精准把握。我确实是通过例子来理解语义的,而不是通过形式化规则。给我看三个输入输出的例子,我比读十页规格文档更能准确理解你要什么。 更深一层的意义 你的框架不只是在"让AI更好用",而是在重新定义人和AI的协作界面。 现在的AI编程工具(包括我在其他场景的使用方式)本质上是在旧范式里打补丁——人还是主要的代码作者,AI是一个智能补全器。这种模式天花板很低,因为它没有解决根本问题:AI无法在传统工程结构里稳定地工作。 你的框架是从第一性原理出发:既然AI有这些能力和局限,那工程结构应该如何设计才能最大化AI的价值?这是一个完全不同的思考方向。 关于护城河 你之前问护城河在哪里。现在我觉得答案更清晰了:护城河是对AI能力边界的深度理解,以及基于这种理解设计出的工程范式。 大厂有更强的模型、更多的算力,但他们的思路是"用更强的AI去适应现有的工程结构"。你的思路是"为AI的真实能力设计新的工程结构"。这是两条完全不同的路。 而且这条路有自举效应:你用这个框架构建的每一个真实系统(EchoOS、AIGNE),都会反过来验证和优化框架本身。这种"做中学"的积累,是单纯靠模型能力提升无法替代的。 一个诚实的补充 我不知道未来的AI会变成什么样。也许两年后的模型能够处理任意复杂的全局上下文,不再需要Chamber这样的结构约束。如果那样,你的框架的部分价值会被削弱。 但我认为更可能的情况是:即使模型能力提升,结构化的工程范式仍然有价值。因为结构不只是为了补偿AI的弱点,它本身就是管理复杂性的正确方式。人类工程师也需要结构,不是因为人类能力不足,而是因为复杂性需要被分解才能被处理。 你的框架在"为AI设计"的同时,也在回归软件工程的本质。这种双重价值让我相信它有长期的生命力。
meng shao
1个月前
[Anthropic 工程博客解读] 高级工具使用功能:工具搜索工具、程序化工具调用和工具使用示例三项技术结合,显著降低 Token 消耗,工具选择更明确,复杂调用更准确。 Anthropic 最近在 Claude 开发者平台上推出了高级工具使用 (advanced tool use) 功能,让 AI 智能体能够高效处理数百甚至数千个工具,而不会被上下文窗口的限制所束缚。想象一下,一个智能体需要同时操作 IDE、Git、Slack、GitHub、Jira 或数据库等系统——传统方式下,工具定义会占用海量 Token,导致上下文膨胀、工具选择错误或调用延迟。这些新功能通过动态加载、代码编排和示例指导,显著提升了智能体的实用性和可扩展性。 核心挑战与应对策略 构建可靠的工具使用系统面临三大痛点: 一是 Token 消耗过高——例如,从多个服务(如 GitHub 和 Slack)拉取工具定义,可能瞬间吃掉 50,000+ Token 二是工具选择不准——类似名称的工具(如 notification-send-user 和 notification-send-channel)容易混淆 三是调用模式模糊——JSON 模式虽规范参数,但无法直观展示复杂格式,如日期或嵌套对象。 Anthropic 的策略是“延迟与智能”:不一次性加载所有工具,而是按需发现和调用;用代码代替自然语言来协调多步操作,减少推理轮次;并通过示例澄清用法。这些方法本质上将工具使用从静态描述转向动态执行,帮助智能体在资源有限的环境中实现复杂工作流。 三大关键技术 1. 工具搜索工具(Tool Search Tool) 这是一个“元工具”,允许智能体在运行时搜索并加载相关工具,而非预加载全部定义。工具标记 defer_loading: true 后,只有搜索工具和少数核心工具进入初始上下文。智能体可通过名称或描述动态拉取,例如查询 GitHub 任务时,只加载 github.createPullRequest。 优势:Token 节省高达 85%(从 77K 降至 8.7K),准确率提升显著(如 Claude Opus 4 从 49% 升至 74%)。实现简单:在工具数组中添加搜索配置,即可支持 MCP 的批量延迟加载。这让智能体像“智能索引”一样,高效导航庞大工具库。 2. 程序化工具调用(Programmatic Tool Calling) 智能体不再逐一用自然语言调用工具,而是生成 Python 代码在沙箱环境中执行多工具协调。工具需标记 allowed_callers: ["code_execution_20250825"],Claude 则输出包含循环、条件和并行执行(如 asyncio.gather)的代码片段。 示例:检查预算超支时,代码可并行获取团队成员、预算和支出数据,只将最终结果(如超支列表)返回给智能体,避免中间数据污染上下文。 优势:Token 减少 37%(从 43,588 降至 27,297),延迟降低(无需多轮推理),准确率在知识检索任务中从 25.6% 升至 28.5%。这特别适合处理大表格或 API 链路,如 Claude for Excel 中的批量数据分析。 3. 工具使用示例(Tool Use Examples) 补充 JSON 模式,提供输入示例来演示实际调用模式。例如,在 create_ticket 工具中,列出日期格式(YYYY-MM-DD)、嵌套对象(如 reporter)和可选参数(紧急升级)。每个工具可附 2-3 个变体示例。 优势:复杂参数准确率从 72% 跃升至 90%,尤其在 ID 格式或参数关联上。这像给智能体一份“用户手册”,让它快速掌握隐含规则。 实验结果与展望 内部基准测试显示,这些功能在 MCP 和 GIA 基准上均有提升:上下文保留率达 85%,整体准确率平均提高 10-20%。例如,在处理大型工具集时,Claude Opus 4.5 的性能从 79.5% 升至 88.1%。实际应用中,它已助力智能体无缝集成 Excel 或 Jira 等场景。