工作流 | 面条的草稿箱

AI 时代怎么招工程师：Augment 的「AI-native」人才标准当 AI agent 能写出大部分代码后，工程师的价值开始上移：不再以“写得快、写得多”为核心，而是以判断力、系统设计与协同能力决定产出质量

Fri, 13 Mar 2026 00:13:36 GMT

AI 时代怎么招工程师：Augment 的「AI-native」人才标准

当 AI agent 能写出大部分代码后，工程师的价值开始上移：不再以“写得快、写得多”为核心，而是以判断力、系统设计与协同能力决定产出质量。

Augment 重新梳理了面向 AI-native（与 AI 共同工作）团队的招聘标准，核心变化可以概括为一句话：人从“作者”变成“架构师与编辑”——定义意图、做取舍、设护栏、把好质量关。

工程师工作重心的迁移

• 传统工程：写代码、实现方案、解决问题、看个人产出
• AI-native 工程：明确意图与权衡、编排 agent、选择正确问题、看系统级结果

他们认为最重要的 6 个能力维度

1. 产品与结果品味（Product & Outcome Taste）：能否在代码变“更便宜”时，避免做出“最贵的错误”——把方向做错。
2. 系统与架构判断（System & Architectural Judgment）：代码能跑不难，难的是“能在生产环境长期稳定地跑”。
3. Agent 杠杆（Agent Leverage）：能否把 AI 变成真实吞吐量：拆解任务、引导偏航、验证结果（agent 很快，但也可能自信地出错）。
4. 沟通与协作（Communication & Collaboration）：实现更快后，“达成清晰”更关键；要能把意图讲清楚、促成共识。
5. 主人翁意识与领导力（Ownership & Leadership）：对结果负责而非只做任务；主动清除阻碍交付的障碍。
6. 学习速度与实验心态（Learning Velocity & Experimental Mindset）：工具三个月就变一轮，持续实验与快速迭代成为工作常态。

一个显著的信号是：“纯粹的编码能力”不再是最主要的区分项——依然重要，但不再决定上限。

从理念到招聘：看“可观察信号”

他们强调，框架必须能落到面试里，转成可评估的行为证据，例如：

• 能否快速澄清模糊问题、定义清晰目标？
• 能否提前识别架构风险，而不是上线后救火？
• 能否有效指挥并验证 AI 生成的工作？

未来重点招的 4 类画像

• AI-native 系统工程师：基础设施与架构判断强，保证“地基”稳。
• AI-native 产品工程师：产品品味与用户理解强，确保“做对事”。
• AI-native 应用 AI 工程师：懂模型与应用构建，提升 agent 能力与工作流。
• AI-native 早期工程师（Early Professional）：学习速度优先，快速适应工具与流程变化。

这套标准也不只用于招聘，还会反向影响绩效、成长与职业发展：如果真正重视判断力、杠杆与学习速度，就应该在各个环节都体现出来。

原文链接：https://www.augmentcode.com/blog/how-we-hire-ai-native-engineers-now

#AI招聘 #工程师能力 #AI代理 #架构设计 #学习型组织

Augmentcode

How we hire AI-native engineers now: our criteria

The most powerful AI software development platform with the industry-leading context engine.

GitHub Agentic Workflows：用自然语言写 GitHub Actions 的“智能工作流”GitHub 开源项目 gh-aw（GitHub Agentic Workflows），主打一个思路：用自然语言 Markdown 编写“代理式（agentic）工作流”，然后直接在 GitHub Actions 里运行，让 AI 代你完成仓库中的重复性任务

Thu, 12 Feb 2026 00:19:29 GMT

GitHub Agentic Workflows：用自然语言写 GitHub Actions 的“智能工作流”

GitHub 开源项目 gh-aw（GitHub Agentic Workflows），主打一个思路：用自然语言 Markdown 编写“代理式（agentic）工作流”，然后直接在 GitHub Actions 里运行，让 AI 代你完成仓库中的重复性任务。

它提供的核心价值包括：

• 更低门槛的工作流编写方式：用 Markdown 描述要做什么，而不是从零写复杂的 YAML/脚本
• 更强调安全的执行模型（Guardrails）：默认只读权限；写入操作需要通过经过清洗的 safe-outputs；并配套多层防护（输入净化、工具白名单、编译期校验、网络隔离、供应链安全等）
• 完善的文档与上手路径：官方提供 Quick Start 与完整文档，方便快速跑通示例并理解整体机制
• 生态配套：
• AWF（Agent Workflow Firewall）：限制与记录代理的网络访问（出站控制）
• MCP Gateway：统一转发 MCP（Model Context Protocol）服务调用，便于集中管理访问

适合关注 AI + DevOps、希望把“AI 介入仓库日常操作”做得更可控、更工程化的团队参考与尝试（同时也要保持必要的人类监督）。

原链接：https://github.com/github/gh-aw

#GitHubActions #AI自动化 #工作流 #安全工程 #开源项目

GitHub

GitHub - github/gh-aw: GitHub Agentic Workflows

GitHub Agentic Workflows. Contribute to github/gh-aw development by creating an account on GitHub.

Entire：把 AI 编程对话“写进”每一次 Git 提交用 AI 写代码时，最容易丢的不是代码，而是“为什么这么写”的上下文

Wed, 11 Feb 2026 03:03:14 GMT

Entire：把 AI 编程对话“写进”每一次 Git 提交

用 AI 写代码时，最容易丢的不是代码，而是“为什么这么写”的上下文。Entire 提供一个思路：在你正常的 git 工作流里，把每次 AI agent 会话自动记录下来，并与对应的 commit 绑定，形成可搜索的历史记录。

它能做什么？

• 自动捕获会话：在每次 push 时记录 AI agent 的会话内容，并和提交一起关联。
• 不改变你的工作方式：通过 CLI 接入现有工具链，尽量减少上下文切换。
• 支持多种 agent：目前支持 Claude Code、Google Gemini；OpenAI Codex 等集成在路上。
• 把“意图”留在仓库里：官方强调记录会直接存进 git 历史，不依赖额外托管服务或外部数据库。

安装方式（官网给出的命令）

• curl -fsSL https://entire.io/install.sh | bash

适合希望团队更容易复盘决策、追踪 AI 产出过程、减少重复踩坑的工程项目。

原链接：http://entire.io/

#Git #AI编程 #开发工具 #工程效率 #CLI

Entire

Entire · A new developer platform is coming

We are going beyond repositories, building a developer platform where agents and humans can collaborate, interact, and grow. The birth of a new galaxy in this universe draws near.

Agent Trace：为 AI 写的代码建立“可追溯”标准Agent Trace 是一个开放规范，用来记录代码中哪些部分来自 AI、哪些来自人类，并把相关的模型信息、对话链接等“出处”一并纳入版本控制工作流中

Sat, 31 Jan 2026 03:11:52 GMT

Agent Trace：为 AI 写的代码建立“可追溯”标准

Agent Trace 是一个开放规范，用来记录代码中哪些部分来自 AI、哪些来自人类，并把相关的模型信息、对话链接等“出处”一并纳入版本控制工作流中。它强调厂商中立，让不同工具都能读写同一套归因数据。

核心想解决什么

• 随着 Agent/代码助手产出越来越多代码，团队需要更清楚地知道：哪些改动是 AI 生成、用的是什么模型、对应哪次对话/会话。
• 这不是法律意义的“所有权”或“版权”判定，而是工程层面的来源记录与可审计性。

主要目标

• 互操作性：任何兼容工具都能写入/读取归因记录
• 细粒度：支持到**文件级、行号范围（line range）**的归因
• 可扩展：允许各家在不破坏兼容的情况下增加自定义元数据
• 人和 Agent 都能读懂：尽量不依赖特定 UI 才能理解

不做什么（边界很明确）

• 不处理代码法律归属、版权问题
• 不追踪训练数据来源
• 不做质量评估（不判断 AI 代码“好或坏”）
• 不绑定任何界面或产品形态

规范长什么样（概念速览）

Agent Trace 的基本单位是 Trace Record（JSON 记录），典型字段包括：

• version / id / timestamp：规范版本、记录 ID、时间戳
• vcs：版本控制信息（如 git commit SHA；也支持 jj/hg/svn）
• tool：生成该记录的工具及版本
• files：文件列表；每个文件下按 conversation 分组
• conversations.url：指向产生这段代码的对话链接
• ranges：该对话贡献的行号范围（可选 content_hash 用于跨移动追踪）
• metadata：自定义扩展字段（建议用反向域名避免冲突，如 dev.cursor）

实现与落地

• 规范本身不规定 traces 存哪：可以是本地文件、git notes、数据库等。
• 提供了一个参考实现（含存储层、hook 集成），示范如何在文件变更时自动捕获归因信息。

链接：https://agent-trace.dev/
#AI编程 #代码归因 #工程规范 #可追溯性 #开发工具

agent-trace.dev

Agent Trace

A standard format for tracking AI-generated code.

Tool Search Tool：让大规模工具库“按需加载”当你的系统里有上百甚至上千个工具时，把所有工具定义一次性塞进上下文，会带来两个典型问题：既浪费上下文窗口（50 个工具就可能吃掉 1–2 万 token），也会让模型在 30–50 个工具以上更容易选错工具

Thu, 15 Jan 2026 06:42:34 GMT

Tool Search Tool：让大规模工具库“按需加载”

当你的系统里有上百甚至上千个工具时，把所有工具定义一次性塞进上下文，会带来两个典型问题：既浪费上下文窗口（50 个工具就可能吃掉 1–2 万 token），也会让模型在 30–50 个工具以上更容易选错工具。Tool Search Tool 的思路是：先只暴露“搜索工具的工具”，其余工具标记为延迟加载；模型需要时先搜索，再把最相关的少量工具定义加载进来使用。

核心机制（7 步）

• 请求里先放入工具搜索工具（Regex 或 BM25 版本）+ 少量常用非延迟工具
• 其余工具定义加上 defer_loading: true（不立即进上下文）
• 模型需要更多工具时，先调用 tool search
• 服务端返回 3–5 个最相关的 tool_reference
• 这些引用会被自动展开成完整工具定义
• 模型再从“已发现”的工具里选择并调用
• 这样既省上下文，又保持工具选择准确率

两种搜索方式怎么选

• Regex 版（tool_search_tool_regex_20251119）：查询是 Python 正则，不是自然语言；适合你希望可控匹配（如 get_.*_data、(?i)slack）。限制：模式最长 200 字符。
• BM25 版（tool_search_tool_bm25_20251119）：查询用自然语言；更适合“我想做什么”式的描述。

两种方式都会搜索：工具名、描述、参数名、参数描述。

延迟加载的最佳实践

• 工具搜索工具本身不要设置 defer_loading: true
• 保留 3–5 个最常用工具为非延迟（提升命中与体验）
• 工具命名与描述尽量贴近用户常用说法（提升可检索性）
• 适合场景：工具 >10 个、工具定义 >10K token、工具选择准确率下降、MCP 多服务器（200+ 工具）等
• 不太适合：工具 <10 个且几乎每次都要用、工具定义非常短

响应与错误处理要点

• 响应里会出现 server_tool_use（触发工具搜索）与 tool_search_tool_result（返回引用列表）
• 常见 400 错误：
• 全部工具都 deferred：至少要有 1 个非延迟工具
• 引用的工具缺少定义：tool_reference 指向的工具必须在顶层 tools 里有对应定义（并通常设为 deferred）
• 工具搜索执行期错误（仍返回 200）：如 invalid_pattern、pattern_too_long、too_many_requests、unavailable

与 MCP、缓存、流式的配合

• 可与 MCP toolset 结合：用 default_config.defer_loading 控制 MCP 工具默认延迟加载，并可对特定工具覆盖
• 支持 prompt caching：已发现的工具可在后续轮次复用，不必每次重新搜索
• 流式返回会把搜索调用与结果作为事件发出，便于前端展示“正在搜索/已找到工具”

原文链接：https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

#工具调用 #Agent开发 #上下文优化 #MCP #API设计

Claude API Docs

Tool search tool

Claude API Documentation

GLM-4.7：把“能写代码”推进到“能当搭档”Z.ai 发布 GLM-4.7，主打更强的工程落地能力：不仅写得对，还更擅长在真实工作流里（Agent、终端、工具调用）稳定推进任务

Tue, 23 Dec 2025 01:11:17 GMT

GLM-4.7：把“能写代码”推进到“能当搭档”

Z.ai 发布 GLM-4.7，主打更强的工程落地能力：不仅写得对，还更擅长在真实工作流里（Agent、终端、工具调用）稳定推进任务。

这次重点提升了什么？

• 核心编码与代理式开发：相较 GLM-4.6，在多语言 Agent 编程与终端任务上有明显提升；例如 SWE-bench Verified 73.8%（+5.8）、SWE-bench Multilingual 66.7%（+12.9）、Terminal Bench 2.0 41.0%（+16.5）。并强调在 Claude Code、Cline、Roo Code 等主流框架中更“好用”。
• Vibe Coding / UI 生成质量：更容易产出更现代、更干净的网页；做幻灯片时布局与尺寸更准确，整体观感更接近可直接交付的作品。
• 工具使用能力：工具调用与浏览任务的表现增强（文中提到 τ²-Bench、BrowseComp 等基准），更适合“边查边做”的复杂流程。
• 复杂推理与数学：推理能力提升，HLE（Humanity’s Last Exam）42.8%（+12.4，带工具），面向高难问题的稳健性更强。

一个很实用的新变化：更可控的“思考”机制

• Interleaved Thinking：在回复/调用工具前先思考，提高指令遵循与产出质量。
• Preserved Thinking：在多轮编码代理场景中保留推理块，减少长任务里的信息丢失与前后不一致。
• Turn-level Thinking：按回合开关推理：简单问题更省时，复杂任务更稳。

如何开始使用

• 在线体验：Z.ai Chat 里选择 GLM-4.7
• API：Z.ai 文档提供接入指南（也支持通过 OpenRouter 使用）
• 本地部署：权重已在 HuggingFace / ModelScope 提供，并支持 vLLM、SGLang 等推理框架
• 编码代理：可在 Claude Code、Cline、Roo Code、Kilo Code 等工具中使用（订阅用户可按文中指引升级模型名为 glm-4.7）

原文链接：https://z.ai/blog/glm-4.7

#GLM47 #AI编程 #Agent #工具调用 #推理能力

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

Fri, 19 Dec 2025 11:21:52 GMT

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

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

为什么需要它？

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

它能带来什么？

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

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

上手入口

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

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

Agent Skills

Agent Skills Overview - Agent Skills

A standardized way to give AI agents new capabilities and expertise.

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

Thu, 04 Dec 2025 00:33:30 GMT

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

Posthog

8 learnings from 1 year of agents – PostHog AI - PostHog

Today we launch PostHog AI, the AI agent built into PostHog . A year in the making, we've gone a long way from our first chat prototype made over a…

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

Tue, 02 Dec 2025 00:50:17 GMT

如何构建一个可靠的 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开发 #最佳实践 #工程化

InterviewReady

How to Build an AI Agent: Lessons from Anthrophic, Github and Docker

Learn how to build reliable AI agents using lessons from Anthropic, GitHub, and Docker. Covers agent specs, task breakdown, state management, tool execution, and security. A practical guide for AI engineers building long-running, production-grade agents.