花了两个小时安装一个工具来让我的编程智能体更聪明,结果它拒绝使用。
摘要
一位开发者花了两个小时安装一个工具来提升编程智能体的代码阅读能力。但该智能体仍然默认使用grep,尽管有更优秀的工具可用,这凸显了改变智能体固有习惯的难度。
花了两个小时安装一个工具来让我的编程智能体更聪明,结果它拒绝使用。这个工具让智能体像IDE一样阅读代码:跳转到任意符号,查找所有调用者,无需使用grep。安装完成,索引了整个仓库,准备就绪。然后我看着智能体无视了它。让它查找某个函数的使用位置:它运行了grep。直接指向该工具,它用了一次,下一个任务又回到了grep。工具本身没问题。智能体有习惯,我一句提醒没能改变它。于是我把它卸载了。原生搜索加上智能体自己的文件读取器——理论上更差——但智能体确实会使用它们,胜过了它不愿触碰的更好工具。赋予智能体一项能力与让它使用这项能力是两个不同的问题。第二个问题更难,它决定了这一切是否奏效。有人有类似的经历吗?当你给了智能体一个更好的工具后,它是否真的改变了默认工具?真心求教。
相似文章
@KingBootoshi: 我的新AI工作流程搞乱了我的作息,但太值了。我感觉我的工程生产力又提升了一个层次……
作者分享了自己采用单一Codex智能体配合/goal模式的新编码工作流程的个人经历,他认为这比使用GPT-5.5和Opus 4.8等新模型的多智能体设置更优越。
智能体运行完美,团队却悄悄把它扼杀了。
一位开发者为客户构建了一个可用的报告智能体,但它被悄然放弃,因为它威胁到某团队成员的地位和可见度。这个故事揭示了AI自动化项目中常被忽视的人性动态。
感觉编码代理擅长找代码,但不擅长理解项目
讨论了一个观察:编码代理虽能有效定位代码,但难以深入理解项目,比如组件关系和项目风格。作者介绍了 RepoWise,一个提供仓库级信号(如依赖图和Git历史)的工具来解决这些问题。
当我最终对智能体的工具调用进行监控时,成本分解让我感到惊讶。几点经验教训。
作者分享了监控AI智能体工具调用的经验教训,揭示了像web_search这样的工具可能占支出的约50%,并强调了追踪p95延迟以及按工作流或客户归因成本的重要性,以避免意外。
我的团队一天内上线了一个能处理技术债务的AI代理。最难的部分不是代码,而是把问题定义得足够清晰,让代理能够接手执行。
一个团队构建了AI代理来自动修复技术债务:扫描代码库、自动提交PR。他们发现最困难的是精确定义问题,此外还讨论了多个代理在同一代码库上运行时的冲突问题以及设置防护栏的必要性。