Search: #工程实践

  1. 如何对 AI 更有“野心”?一位 Claude 开发者的实用指南很多时候,限制 AI 发挥上限的并不是模型本身,而是我们对任务的想象力

    如何对 AI 更有“野心”?一位 Claude 开发者的实用指南

    很多时候,限制 AI 发挥上限的并不是模型本身,而是我们对任务的想象力。在大多数人还在让 AI 改写邮件、生成模板 PPT 时,Anthropic 的 Claude 开发者 Felix Rieseberg 分享了一份“野心指南”,教我们如何摆脱浅层用法,真正释放大模型的生产力潜能。

    他将使用 AI 的“野心”拆解为四个维度,其中三个最值得深入实践:

    1. 提升“高度”(Altitude):从交待动作,到追求最终结果

    不要只让模型完成细碎的微观任务,试着让它在更高的抽象层级上思考:

    • 思考目标背后的目标:以前是让 AI 修复一个 Bug,现在可以试着让它构建机制“确保应用长期无崩溃”;
    • 重构工作流:在制作季度业务汇报时,不要只让它填模版,而是喂给它全局原始数据,让它推导出最紧迫的 3 个关键决策,甚至设计一套能取代低效周会的实时监控方案。

    2. 挖掘“深度”(Depth):像顶尖行业专家一样死磕

    不满足于表面应付,把模型推到底层工具和方法论的极限:

    • 坚持使用顶级工具:不要满足于让 AI 输出简陋的表格,逼迫它使用真正的数据科学库、数据库与统计模型;
    • 设定“不讲道理”的高目标:告诉模型一个看似严苛的指标(比如将耗时压缩 90%),并坚定告诉它“这完全可行,请继续探索”;
    • 对抗性验证与外部评判:给 AI 原始数据,让它反向推翻团队原本的业务假设;同时引入外部执行工具或测试集来检验输出,而不是让模型自己给自己打分。

    3. 拓展“广度”(Range):打破单兵思维,调动跨界视角

    AI 极大地降低了调用跨学科经验的边际成本:

    • 用“动词”替换“名词”:例如季度报告不仅是“一份 PPT”,本质是“在 30 分钟内让决策层在不确定中达成共识”。有了行为导向,就更容易引入心理学、传播学甚至侦探视角的逻辑;
    • 组建跨角色智囊团:在复杂方案评估中,引入做空机构、法务审计、调查记者等不同维度的分析逻辑来审视方案盲区,但要让模型“执行对应专业的实际调研方法”,而非单纯的角色扮演。

    ---

    核心启发

    心理学上有个概念叫“自我效能感”(Self-efficacy)——人类往往习惯自我设限,只敢在熟悉的舒适区里设定目标。但在 AI 模型能力每隔几周就跃升一次的时代,最先拉开差距的,往往是谁更敢于提出那些看似“过分”的问题与目标。

    原文链接:https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/

    #人工智能 #Claude #提示词工程 #认知升级 #工作流 How to be more ambitious: A tutorial for humans with models

  2. 做个出色的 Emoji 搜索,真不需要杀鸡用牛刀最近业内热议 Linear 将新型分类推理模型 Jev 引入 Emoji 选择器,体验提升显著

    做个出色的 Emoji 搜索,真不需要杀鸡用牛刀

    最近业内热议 Linear 将新型分类推理模型 Jev 引入 Emoji 选择器,体验提升显著。但开发者 Max Leiter 指出:别把所有分类与检索任务都当成需要大模型推理的“钉子”。

    在针对 4,668 个 Emoji(包含 Unicode 与社区自定义表情)的实测基准测试中:

    • 成本与延迟差距巨大:Jev 每次检索需将整个候选池灌入上下文(单次耗费近 6 万 tokens),成本比 Embedding 高出 1,000 到 10,000 倍,延迟约为 2 倍,且存在服务不稳定的风险;其检索效果虽有微弱提升,但并不具压倒性优势。
    • 纯向量检索更高效:利用 text-embedding-3-large 搭配 pgvector,或直接在浏览器端运行约 35 MB 的小模型(bge-small-en-v1.5)配合二进制向量(Binary Embeddings),就能实现低成本甚至零成本、毫秒级响应的语义检索。
    • 选型建议:
    • 已知集合匹配(如 Emoji、文档检索):优先使用 Embedding 向量检索。
    • 已知标签分类:使用小型分类器或微调模型,成本更低、速度更快。
    • 何时使用 Jev 等推理模型:仅在结果依赖复杂上下文理解、需要逻辑推理而无法单纯依靠向量空间距离解决时,才值得投入高昂成本。

    原文链接:https://maxleiter.com/blog/embedding-emoji-search

    #人工智能 #向量检索 #架构设计 #工程实践 You don't need Jev for good emoji search | Max Leiter

  3. Agent-native 应用:把“功能”变成“结果”这篇文章提出一种新范式:与其把产品能力写成一堆固定功能,不如构建一个能反复调用工具、直到达成目标的“软件代理(agent)”

    Agent-native 应用:把“功能”变成“结果”

    这篇文章提出一种新范式:与其把产品能力写成一堆固定功能,不如构建一个能反复调用工具、直到达成目标的“软件代理(agent)”。核心在于:让代理拥有与用户同等的操作能力(UI 能做的,代理也能通过工具做到),并把工具设计成足够原子化的“积木”。这样,新功能往往不再是写代码,而是写一段描述结果的提示词;同时,用户提出的意外需求会推动系统“涌现”出新用法,并反过来指导你补齐工具与能力缺口。

    五个核心原则

    • 对等(Parity):任何 UI 动作,代理都应能通过工具实现同样的结果;否则代理会卡死。
    • 粒度(Granularity):工具是原子能力;“功能”是代理在循环中用工具达成的结果。改行为优先改提示词,而不是重构代码。
    • 可组合(Composability):有了原子工具 + 对等能力,就能通过新提示词快速拼出新“功能”(开发者/用户都能做)。
    • 涌现能力(Emergent capability):用户会提你没设计过的需求;代理若能组合工具完成,就是新机会;若失败,则暴露工具缺口。
    • 持续变好(Improvement over time):通过沉淀上下文(context 文件)与迭代提示词,应用可在不发版的情况下持续变强。

    落地方法(把原则变成工程实践)

    • 先做“能力地图”:列出用户能做的事,逐项确认代理具备创建/读取/更新/删除(CRUD)能力,避免“能新建不能修改/删除”的断腿体验。
    • 先原语、后领域工具:先用文件、bash、读写等基础工具跑通;再为高频模式加领域工具,用于效率、校验、术语锚定,但不要把“判断”写进工具里。
    • 文件作为通用接口:文件天然可读、可审计、可迁移,代理也最擅长操作;内容放文件、结构化高频数据放数据库(或混合:文件作可读真相,DB 做索引与性能)。
    • 明确完成信号:不要靠“看起来差不多了”判断结束;让工具/编排层返回明确的 complete 信号,避免无限循环或半成品。
    • 透明的代理行为:工具调用、进度、状态变化要让 UI 可见;“沉默的代理”会让用户觉得坏了。
    • 把“授权”做成产品能力:根据风险与可逆性决定自动执行还是强确认;尤其是发送邮件、发布内容等高风险动作。

    对移动端的启示

    • 移动应用容易被后台杀死,代理任务却可能很长:需要checkpoint/恢复机制,尽可能在每次工具结果后存档。
    • iCloud 之类的文件同步能让多设备共享“同一工作区”,但要处理冲突与未下载文件等边界。

    原链接:https://every.to/guides/agent-native

    #AgentNative #软件代理 #AI产品 #工具调用 #产品架构 Agent-native Architectures

  4. Agent Skills:给 AI Agent “装上技能包”Agent Skills 是一种开放格式:把一套可复用的指令、脚本与资源打包成「技能」,让智能体在需要时按需加载,从而更准确、更高效地完成真实工作

    Agent Skills:给 AI Agent “装上技能包”

    Agent Skills 是一种开放格式:把一套可复用的指令、脚本与资源打包成「技能」,让智能体在需要时按需加载,从而更准确、更高效地完成真实工作。

    为什么需要它?

    • 智能体能力越来越强,但常缺少上下文与流程知识;技能把这些程序化经验与团队/组织知识变成可携带、可版本管理的包
    • 对作者:一次构建,多处部署,跨多种智能体产品复用
    • 对企业与团队:把组织最佳实践沉淀为可审计、可迭代的工作流

    它能带来什么?

    • 领域专长:把法律审阅、数据分析等专业流程封装成可复用指南
    • 新能力扩展:例如自动做演示文稿、搭建 MCP Server、分析数据集等
    • 可重复的工作流:多步骤任务标准化,稳定且可追踪
    • 互操作性:同一技能可在不同“支持技能”的工具/产品间通用

    生态与开放性
    该格式最初由 Anthropic 提出并以开放标准发布,已被多种 AI 开发工具与产品支持,并在 GitHub 上开放协作。

    上手入口

    • 了解技能是什么、格式规范、如何集成、示例技能与参考库(校验与生成 prompt XML)

    原链接:https://agentskills.io/home
    #AI代理 #开放标准 #工作流 #知识沉淀 #开发者工具 Agent Skills Overview - Agent Skills

  5. PostHog AI: 开发 AI 智能体一年后总结的 8 个教训PostHog 团队在开发其内置 AI 智能体 PostHog AI 的一年中,积累了丰富的实践经验

    PostHog AI: 开发 AI 智能体一年后总结的 8 个教训

    PostHog 团队在开发其内置 AI 智能体 PostHog AI 的一年中,积累了丰富的实践经验。从一个简单的聊天原型到一个能处理复杂分析任务的智能助手,他们总结了以下 8 个核心教训:

    1. 模型升级是推土机
    AI 模型的持续进步是开发中最强大的变量。曾经复杂的问题,如多步推理和工具调用,随着模型能力的提升而变得简单。密切关注模型发展至关重要.

    2. 循环智能体优于固定工作流
    相较于图表式的固定工作流,单一的循环智能体(Agent)更为灵活和强大。它能在执行任务中自我纠正,避免了工作流中常见的上下文丢失问题.

    3. 单一循环胜过子智能体架构
    复杂的子智能体架构听起来很智能,但在实践中容易因层层抽象而丢失关键信息,导致性能下降。一个简单、扁平的 LLM 循环反而能涌现出惊人的能力.

    4. “待办事项”是超能力
    让 LLM 在每一步操作后都使用一个简单的 `todo_write` 工具来规划下一步,这种看似简单的机制能有效帮助模型在复杂任务中保持专注和连贯性.

    5. 上下文是关键
    用户输入往往是模糊的,AI 需要广泛的背景知识才能准确理解. PostHog AI 通过 `/init` 命令自动学习项目信息,为智能体提供核心上下文,从而显著提升任务成功率.

    6. 展示每一步,建立信任
    透明度是建立用户信任的基石. 与其隐藏过程,不如将智能体的思考、工具调用甚至失败的尝试全部展示给用户. 这比一个完美的“黑箱”更能赢得信赖.

    7. 警惕 AI 框架的陷阱
    在 AI 技术飞速发展的今天,LangChain 等高级框架可能会过早地锁定技术选型. 在生态系统稳定之前,坚持使用更底层的库可能是更明智的选择.

    8. 评估(Evals)并非全部
    自动化评估很有价值,但无法替代对真实用户行为的分析. 通过观察实际使用中的 LLM 轨迹 (Traces),团队能发现评估中无法覆盖的、更深刻的问题.

    总而言之,构建高效的 AI 智能体需要拥抱变化、简化架构、重视上下文和透明度,并始终立足于真实的用户场景.

    原文链接: PostHog Blog

    #AI #Agent #LLM #工程实践 #PostHog 8 learnings from 1 year of agents – PostHog AI - PostHog

  6. 如何构建一个可靠的 AI Agent?随着 AI 的发展,构建能长期稳定运行且行为可靠的 Agent 已成为 AI 工程师的核心竞争力之一

    如何构建一个可靠的 AI Agent?

    随着 AI 的发展,构建能长期稳定运行且行为可靠的 Agent 已成为 AI 工程师的核心竞争力之一。借鉴 Anthropic、GitHub 和 Docker 的最新实践,我们可以遵循以下五个关键步骤来打造强大的 AI Agent。

    1. 从明确的规范开始
    当前多数 Agent 因指令模糊、状态和工作流管理不善而表现不佳。一份好的规范应明确其角色、技术栈、预期输出示例和行为边界(如数据访问权限、API 速率限制等)。不要只依赖“你是一个有用的助手”,而是给 Agent 一份定义清晰的合同。

    2. 将工作分解为可验证的小任务
    与其给出一个模糊的大任务(例如“为我构建一个 X 的克隆”),不如将其分解为具体、可验证的步骤,如“计划 → 编码 → 测试 → 部署 → 监控”。为 Agent 提供清晰的任务列表和严格的工作流程,能有效避免因模糊性导致的失败。

    3. 在模型外部持久化状态
    为了让 Agent 能够处理长时间运行的任务并在会话中断后恢复,需要将其状态(如进度日志、任务清单、文件差异等)存储在外部文件或数据库中。这确保了 Agent 能够随时检索到完成任务所需的相关上下文。

    4. 避免过度填充上下文窗口
    将所有信息塞进系统提示会导致响应缓慢和高昂的 Token 成本。更高效的策略是让 Agent 生成代码来调用外部工具或 API,然后仅将结果返回给模型。这种方法能显著节省 Token,使 Agent 响应更快、成本更低。

    5. 在沙箱中运行高风险操作
    如果 Agent 需要执行代码,必须将其置于沙箱环境中,并严格限制其可用的工具和文件系统访问权限。为 Agent 设置明确的“护栏”,可以有效降低应用和服务器面临的风险。

    总而言之,一个成功的 Agent 由三部分组成:行为(清晰的规范)、状态(外部持久化)和护栏(安全限制)。

    原文链接: https://interviewready.io/blog/how-to-build-an-ai-agent-lessons-from-anthrophic-github-and-docker

    #AIAgent #AI开发 #最佳实践 #工程化 How to Build an AI Agent: Lessons from Anthrophic, Github and Docker

1px