工程效率 | 面条的草稿箱

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-native 应用：把“功能”变成“结果”这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”

Mon, 12 Jan 2026 08:37:11 GMT

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产品 #工具调用 #产品架构

every.to

Agent-native Architectures

A technical guide for building applications where agents are first-class citizens

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.